From nobody Tue Nov 1 01:41:50 2016 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 0786612954B for ; Tue, 1 Nov 2016 01:41:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securityinnovation.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 TyyQqdhqnCEA for ; Tue, 1 Nov 2016 01:41:47 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 50D39129549 for ; Tue, 1 Nov 2016 01:41:47 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 12so123600345uas.2 for ; Tue, 01 Nov 2016 01:41:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hWzRYSF+ByizQ1W5+2W/GXsrgX2/W086d4InnQDhstY=; b=YtwqeUAbfZ9yw+NaX12lSz7LxE51MSrzelX4mknhn3l82KMSnKYqAi0NrmgnRwrMbR uF4hY9FXvEULRzxYNQWwJ9UvSSy3Cm+QGQNAsYWTlTY6AvddzooXDJkPs4LufK3IGW1Z EAMj0JDAeylIQnkCDCwjOqpE50iK2w7ewb+eI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hWzRYSF+ByizQ1W5+2W/GXsrgX2/W086d4InnQDhstY=; b=PEIW70+617vGryrSOAKeTfC9i2iMt49xBIXsYCdbLakI1AR5OY+Mv2ySlO7vv6xItv 6ukoj6jWvhvtHiGn9uKnFuLou4ImD3RF8Uesjxr7eQ4K8SCoPsgvek7kgNbDnIgSntg5 q9D/a1chxYqyzpdUeVK3IpQYAmYLF+SnBkxbu9R+NyneyYRbn/iBuXvmpERDc3ggXVnY kUpl1hgCwBmReeSRHxGzqyWmTmBPJBRhKL7wos1tuic694hNHZ8MPHhOPvs2qNIQ7Y+e irl+F3mgsSxG5hztzg+PDq8y/geGEJVgd5fpgmwTE2caCofQDjUCraPtHM/yNJqwMcJW MyNQ== X-Gm-Message-State: ABUngvdweWvV1GdgGmcnFiSqoXI4C8gQPoLeKmzzDmMGTPjjmXIBFCxz5Th8NbvGUEjjCqiCztNjGINX8O6ms1mY X-Received: by 10.159.35.129 with SMTP id 1mr26476072uao.33.1477989706278; Tue, 01 Nov 2016 01:41:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.80.122 with HTTP; Tue, 1 Nov 2016 01:41:44 -0700 (PDT) In-Reply-To: References: From: William Whyte Date: Tue, 1 Nov 2016 04:41:44 -0400 Message-ID: To: Nick Sullivan Content-Type: multipart/alternative; boundary=94eb2c03ec286cbd850540394b64 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 01 Nov 2016 08:41:49 -0000 --94eb2c03ec286cbd850540394b64 Content-Type: text/plain; charset=UTF-8 I'm confused by the line "These messages are not encrypted", because on a plain reading it could mean that the authenticator is sent outside the encrypted TLS session. That would be bad because it would mean that clients that wanted to authenticate themselves but to the server only wouldn't be able to use this mechanism. I assume that's not the intent? If that isn't the intent, suggest rephrasing as "These messages are not encrypted, other than the encryption provided on transmission by the TLS session". Cheers, William On Mon, Oct 31, 2016 at 5:29 PM, Nick Sullivan wrote: > > draft-sullivan-tls-exported-authenticator-00> > > > I just posted a new Internet-Draft called "Exported Authenticators in TLS" > in the TLS working group. > > The intent of this draft is to enable participants in a TLS connection to > prove ownership of additional certificates. This differs from previous > proposals (https://tools.ietf.org/html/draft-sullivan-tls-post- > handshake-auth-00) in that these proofs are not sent as part of the TLS > connection, but instead exported so that they can be sent out of band (as > part of an application layer message, for example). > > This proposal should enable a radical simplification of the Secondary > Certificate Authentication in HTTP/2 proposal ( > https://tools.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01), > and should generally be a useful tool for binding a certificate ownership > proof to a TLS connection. > > Nick Sullivan > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c03ec286cbd850540394b64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm confused by the line "These messages are not = encrypted", because on a plain reading it could mean that the authenti= cator is sent outside the encrypted TLS session. That would be bad because = it would mean that clients that wanted to authenticate themselves but to th= e server only wouldn't be able to use this mechanism. I assume that'= ;s not the intent? If that isn't the intent, suggest rephrasing as &quo= t;These messages are not encrypted, other than the encryption provided on t= ransmission by the TLS session".

Cheers,
=
William

On Mon, Oct 31, 2016 at 5:29 PM, Nick Sullivan <nicholas.sullivan@gmail.com> wrote:
I just posted = a new Internet-Draft called "Exported Authenticators in TLS" in t= he TLS working group.

The intent of this draft is to enabl= e participants in a TLS connection to prove ownership of additional certifi= cates. This differs from previous proposals (https://tools.ietf.org/html/draft-sullivan-tls-pos= t-handshake-auth-00) in that these proofs are not sent as part of = the TLS connection, but instead exported so that they can be sent out of ba= nd (as part of an application layer message, for example).

This prop= osal should enable a radical simplification of the Secondary Certificate Au= thentication in HTTP/2 proposal (https://tool= s.ietf.org/html/draft-bishop-httpbis-http2-additional-certs-01), and should generally be a useful tool for binding a certificate ownersh= ip proof to a TLS connection.

Nick Sullivan

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--94eb2c03ec286cbd850540394b64-- From nobody Tue Nov 1 08:45:22 2016 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 388FD129841 for ; Tue, 1 Nov 2016 08:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JpyWKnAbRNBr for ; Tue, 1 Nov 2016 08:45:18 -0700 (PDT) Received: from mail-ua0-x232.google.com (mail-ua0-x232.google.com [IPv6:2607:f8b0:400c:c08::232]) (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 78DC0129AE0 for ; Tue, 1 Nov 2016 08:45:17 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id 12so131767873uas.2 for ; Tue, 01 Nov 2016 08:45:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=r3SrC7K+dlnneIDhH6rweQDUKVi8sdKBgkRXkwgFlIo=; b=rPl+CSQQUUdCGelPWyLvic/0PrPBVGmpMWPKBj7sxA8qXrAx3xEmWIaHm6uNa+xEvy Os7G5uZYkwkk8YBOX7SSCaxmv2+X5LhCf8/N6+MWOd0VmEsVsfSFaiLDq1kooHwk14HA eipjodBAw39FzrDD9igA/r2X6dPbPQBmez+rcUuxMpB44QUV6pilVwoGf3Pj00VercbH Rjnog9RHIj2u2jeGXEZs59CVdl4VNsJggnVCQ1og1bUykO3iPhJCYfRpRLgTr+0FGHfi oiYIwiAeZ4xdeqkyd4lPCYtbf77Qr9rpy2XPMSEf9+y0ogMlKpOxfeHRy0O+E0UffMhw RqZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=r3SrC7K+dlnneIDhH6rweQDUKVi8sdKBgkRXkwgFlIo=; b=PRUv9TISaHyGs7Tzz8cNU4MZ2R6GYuf1Mh3MjllWIkW7zaG9Lp+QS39IOsAw8fMpRM 6oVNpSG2zOV4ZZK4kAoRZoLmnylqRIoD4MIGXn6Qo4n++qHXlrEhIv9QxwkwGYtzaDVX r6558fB6X1qpHEbpaH2Mmp9d9o08ryDvhF4xeF5K4TFd6clLj1AQhJ2/CaOHLHpBbsfc eZ2zRADHxpT2TEFC6bUFLWlj65Q7c29jhSCx0jR6RPGU97BWZC8ryt5n9tW5eyGnX7VE s9c5DDYWptuSYWF6bycLXRAqtTMGouqwgLzGsds2OUfVDFNXY7w47fTF6uLZ/U312z8e idcw== X-Gm-Message-State: ABUngvekgDCkEeA6884NQYHAYbaB5aEJ+guaRCrDCUEWG05BsrNVd7zSYVC3wW9+mQZIfjCFfNg+Ruv5mTjSyg== X-Received: by 10.159.40.101 with SMTP id c92mr27854198uac.111.1478015116337; Tue, 01 Nov 2016 08:45:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.68.135 with HTTP; Tue, 1 Nov 2016 08:45:15 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Tue, 1 Nov 2016 08:45:15 -0700 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 01 Nov 2016 15:45:20 -0000 On Mon, Oct 31, 2016 at 2:28 PM, Eric Rescorla wrote: > Watson, > > Thanks for your comments! > > On Mon, Oct 31, 2016 at 11:41 AM, Watson Ladd wro= te: >> >> Hello, >> >> Looking at the history of TLS implementation attacks we see that many >> result from the standard not strictly enough prescribing behavior, >> particularly of the state machine. This draft does not actually fix >> this problem, but continues to present example flows without >> explicitly requiring them to be the only possible flows. > > > >> For example, consider HelloRetryRequest. Do servers only send one of >> these per connection, or can it be resent multiple times? Obviously >> there is a DoS possibility here, but I do not see where this behavior >> is explicitly defined. I think we should require that the server only >> ever sends one HelloRetryRequest, and then terminates the connection >> if the ClientHello is unacceptable. > > > > The server is forbidden to send multiple HRRs and the client is required > to enforce it. See: > > https://tlswg.github.io/tls13-spec/#hello-retry-request > > I agree that we don't require the server to behave this way. I can fix th= e > draft to say this. That sounds good. The more we can turn bugs into ones that violate the spec, the easier it will be to get them fixed. (Hopefully) > > >> At no point is it stated that only >> the example flows should be supported. I would prefer more clarity >> about what messages are to be expected when, especially with alerts. > > > Actually the text does say something here: > https://tlswg.github.io/tls13-spec/#handshake-protocol > > "Protocol messages MUST be sent in the order defined below (and shown in = the > diagrams in Section 2). A peer which receives a handshake message in an > unexpected order MUST abort the handshake with an =E2=80=9Cunexpected_mes= sage=E2=80=9D > alert. Unneeded handshake messages are omitted, however." > > However, this text was also in 5246, so I think there's a fair argument > that it's not strong enough. I'm not quite sure how to make it better. > Suggestions? So I was reading in order, so I saw the diagrams first, which seemed like examples and then missed this sentence in the draft. Maybe a sentence in section 2 would help? > > >> ECDSA cannot be used with x25519 or x448, but the draft seems to >> require support in TLS 1.2 for this as a consequence of its >> description of the fallback mode. > > > I don't *think* that that's true: can you point to the specific text that > you are concerned with? It's the interaction between https://tlswg.github.io/tls13-spec/#negotiated-groups and the statement that ECDSA needs to be supported with any curve appearing in the supported_groups extension when negotating a TLS 1.2 hello. We explicitly call x25519 an elliptic curve there. Yes, I doubt anyone will end up making an implementation that does this (except by accident). > > >> ALPN, resumption, and 0-RTT remain problematic. For instance we see >> that 0-RTT data is sent with the same ALPN state when the PSK was >> derived, but this could be different from the ALPN transmitted and >> negotiated during the handshake, which is explicitly allowed later in >> the document. I do not understand what is supposed to happen in this >> scenario. > > > Here's the relevant text: > https://tlswg.github.io/tls13-spec/#early-data-indication > > "If any of these checks fail [ALPN is in the list above] the server MUST = NOT > respond with the extension and must discard all the remaining first fligh= t > data (thus falling back to 1-RTT). If the client attempts a 0-RTT handsha= ke > but the server rejects it, it will generally not have the 0-RTT record > protection keys and must instead trial decrypt each record with the 1-RTT > handshake keys until it finds one that decrypts properly, and then pick u= p > the handshake from that point." > > Is there anything else you'd like to see here? > >> Appendix B removes the text about upper-layer protocol interactions >> with 0-RTT I provided, merely discussing the API. I think this is a >> mistake: how 0-RTT should be used safely depends on the upper-layer >> protocol, and can be complex. API guidance is not enough. > > > This ended up in the main text: > https://tlswg.github.io/tls13-spec/#zero-rtt-data > > "Protocols MUST NOT use 0-RTT data without a profile that defines its use= . > That profile needs to identify which messages or interactions are safe to > use with 0-RTT. In addition, to avoid accidental misuse, implementations > SHOULD NOT enable 0-RTT unless specifically requested. Special functions = for > 0-RTT data are RECOMMENDED to ensure that an application is always aware > that it is sending or receiving data that might be replayed." > > Is this missing pieces you think we need? Yes, thanks for pointing out where I missed it. > > >> There is still a note about needing a channel binding mechanism in the >> text. I think this should be resolved soon so it can be analyzed, >> probably built on top of the exporter mechanism. Either that, or we >> consciously punt and remove the note and replace with something else. > > > The idea here is that we need a separate draft that just says "use export= ers > with > label X". I think we remove the note and see if we can get someone to wri= te > that draft. > > >> As for process, I support the idea of having a last call on November >> 20th, and then completing the security analysis by January 20th (or >> whatever date was decided). This will prevent a flurry of changes >> potentially breaking things. > > > That's the idea. > > -Ekr > >> >> Sincerely, >> Watson Ladd >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > --=20 "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Nov 1 10:17:49 2016 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 A8B6C1295AE for ; Tue, 1 Nov 2016 10:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.021 X-Spam-Level: X-Spam-Status: No, score=-2.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 T55saHt7_vIM for ; Tue, 1 Nov 2016 10:17:45 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0137.outbound.protection.outlook.com [104.47.32.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C247C12958D for ; Tue, 1 Nov 2016 10:17:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ebCjo1vuSqXq5v3YynJDA/1qn9JG7MuRNwTl4l0JqCs=; b=FGGIiUBeRasf/PLI+HqLvMgtpn6gaJ+ZBqBn8oN9ZOAbjvRafPQJyY2BR2XMCtEU2KvWMCjB0LxiFZPs9BWR9zIxNTjZLzcV8TBBM+ZBE2IRCEs30bKWMh93KWo9pMq9RjjZRDM+qfspKkd5Yc3uSkpRhip4ejZv0LUQ+agVKT0= Received: from BN3PR0301MB0836.namprd03.prod.outlook.com (10.160.154.146) by BN3PR0301MB0834.namprd03.prod.outlook.com (10.160.154.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Tue, 1 Nov 2016 17:17:39 +0000 Received: from BN3PR0301MB0836.namprd03.prod.outlook.com ([10.160.154.146]) by BN3PR0301MB0836.namprd03.prod.outlook.com ([10.160.154.146]) with mapi id 15.01.0693.009; Tue, 1 Nov 2016 17:17:40 +0000 From: Andrei Popov To: William Whyte , Nick Sullivan Thread-Topic: [TLS] draft-sullivan-tls-exported-authenticator-00 Thread-Index: AQHSM74CyYj9W0c/pkaJmajQ9ivOJ6DD0BAAgACP+HA= Date: Tue, 1 Nov 2016 17:17:39 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8::1d2] x-ms-office365-filtering-correlation-id: a1240354-5abd-492d-8094-08d4027afbea x-microsoft-exchange-diagnostics: 1; BN3PR0301MB0834; 7:mXlZG33kU2a0ZE40AwbDAf9M8T0ifMs64efR8FcfQttvjOT382Hag/pWbUyrDwlEJjrDmfvi0Di9izk1/ZZDYMcqBygabUwhekLQxGdv7McbmoWLqlk1Y37hUo83MvCH/ettPUoW3/mJh44/2G6D5lUzpZf7eAsPEIaS0iNHXX3ccCEa+nQiJaV2/uKjjP119mrW3t7d+ES9gRo2rJvwoHb20SI3PLZlAU1CO5NdxWfyV4YR5UemxQlvdf3jhtFuZ/c4kGiOnyhDGVHpQbl4wS2l4qcrdQvMfRlFjn4mmp0P4Ppg4MoR9zY62MehMY/PP/cFb6odRbXoJOB4VBsddzk4o9U7T/UOZ7OD04SPOm8WimHxilTJI5Pug9CnhseH x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR0301MB0834; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(60795455431006)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040176)(6045074)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6046074)(6072074); SRVR:BN3PR0301MB0834; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0834; x-forefront-prvs: 01136D2D90 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(189002)(377454003)(199003)(97736004)(189998001)(230783001)(5002640100001)(76576001)(19617315012)(68736007)(10090500001)(3280700002)(3660700001)(87936001)(106356001)(105586002)(86362001)(99286002)(106116001)(5001770100001)(586003)(86612001)(19609705001)(8936002)(16236675004)(7846002)(561944003)(50986999)(54356999)(9686002)(122556002)(19300405004)(8990500004)(8676002)(7736002)(7906003)(33656002)(6116002)(102836003)(74316002)(5005710100001)(101416001)(19580405001)(81156014)(81166006)(790700001)(76176999)(19580395003)(10400500002)(19625215002)(77096005)(2900100001)(15975445007)(7696004)(5660300001)(92566002)(10290500002)(2950100002)(4326007)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0834; H:BN3PR0301MB0836.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BN3PR0301MB083670BEC8B1B0B40D532D8C8CA10BN3PR0301MB0836_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2016 17:17:39.7334 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0834 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 01 Nov 2016 17:17:48 -0000 --_000_BN3PR0301MB083670BEC8B1B0B40D532D8C8CA10BN3PR0301MB0836_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 WWVzLCB0aGlzIGxpbmUgaGFzIGNvbmZ1c2VkIG1lIGFzIHdlbGwuDQoNCkNoZWVycywNCg0KQW5k cmVpDQoNCkZyb206IFRMUyBbbWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg T2YgV2lsbGlhbSBXaHl0ZQ0KU2VudDogVHVlc2RheSwgTm92ZW1iZXIgMSwgMjAxNiAxOjQyIEFN DQpUbzogTmljayBTdWxsaXZhbiA8bmljaG9sYXMuc3VsbGl2YW5AZ21haWwuY29tPg0KQ2M6IHRs c0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIGRyYWZ0LXN1bGxpdmFuLXRscy1leHBvcnRl ZC1hdXRoZW50aWNhdG9yLTAwDQoNCkknbSBjb25mdXNlZCBieSB0aGUgbGluZSAiVGhlc2UgbWVz c2FnZXMgYXJlIG5vdCBlbmNyeXB0ZWQiLCBiZWNhdXNlIG9uIGEgcGxhaW4gcmVhZGluZyBpdCBj b3VsZCBtZWFuIHRoYXQgdGhlIGF1dGhlbnRpY2F0b3IgaXMgc2VudCBvdXRzaWRlIHRoZSBlbmNy eXB0ZWQgVExTIHNlc3Npb24uIFRoYXQgd291bGQgYmUgYmFkIGJlY2F1c2UgaXQgd291bGQgbWVh biB0aGF0IGNsaWVudHMgdGhhdCB3YW50ZWQgdG8gYXV0aGVudGljYXRlIHRoZW1zZWx2ZXMgYnV0 IHRvIHRoZSBzZXJ2ZXIgb25seSB3b3VsZG4ndCBiZSBhYmxlIHRvIHVzZSB0aGlzIG1lY2hhbmlz bS4gSSBhc3N1bWUgdGhhdCdzIG5vdCB0aGUgaW50ZW50PyBJZiB0aGF0IGlzbid0IHRoZSBpbnRl bnQsIHN1Z2dlc3QgcmVwaHJhc2luZyBhcyAiVGhlc2UgbWVzc2FnZXMgYXJlIG5vdCBlbmNyeXB0 ZWQsIG90aGVyIHRoYW4gdGhlIGVuY3J5cHRpb24gcHJvdmlkZWQgb24gdHJhbnNtaXNzaW9uIGJ5 IHRoZSBUTFMgc2Vzc2lvbiIuDQoNCkNoZWVycywNCg0KV2lsbGlhbQ0KDQpPbiBNb24sIE9jdCAz MSwgMjAxNiBhdCA1OjI5IFBNLCBOaWNrIFN1bGxpdmFuIDxuaWNob2xhcy5zdWxsaXZhbkBnbWFp bC5jb208bWFpbHRvOm5pY2hvbGFzLnN1bGxpdmFuQGdtYWlsLmNvbT4+IHdyb3RlOg0KPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC88aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0 LXN1bGxpdmFuLXRscy1leHBvcnRlZC1hdXRoZW50aWNhdG9yLTAwPmRyYWZ0LXN1bGxpdmFuLXRs cy1leHBvcnRlZC1hdXRoZW50aWNhdG9yLTAwPjxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtc3VsbGl2YW4tdGxzLWV4cG9ydGVkLWF1dGhlbnRpY2F0b3ItMDA+DQpJIGp1c3QgcG9z dGVkIGEgbmV3IEludGVybmV0LURyYWZ0IGNhbGxlZCAiRXhwb3J0ZWQgQXV0aGVudGljYXRvcnMg aW4gVExTIiBpbiB0aGUgVExTIHdvcmtpbmcgZ3JvdXAuDQoNClRoZSBpbnRlbnQgb2YgdGhpcyBk cmFmdCBpcyB0byBlbmFibGUgcGFydGljaXBhbnRzIGluIGEgVExTIGNvbm5lY3Rpb24gdG8gcHJv dmUgb3duZXJzaGlwIG9mIGFkZGl0aW9uYWwgY2VydGlmaWNhdGVzLiBUaGlzIGRpZmZlcnMgZnJv bSBwcmV2aW91cyBwcm9wb3NhbHMgKGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1z dWxsaXZhbi10bHMtcG9zdC1oYW5kc2hha2UtYXV0aC0wMCkgaW4gdGhhdCB0aGVzZSBwcm9vZnMg YXJlIG5vdCBzZW50IGFzIHBhcnQgb2YgdGhlIFRMUyBjb25uZWN0aW9uLCBidXQgaW5zdGVhZCBl eHBvcnRlZCBzbyB0aGF0IHRoZXkgY2FuIGJlIHNlbnQgb3V0IG9mIGJhbmQgKGFzIHBhcnQgb2Yg YW4gYXBwbGljYXRpb24gbGF5ZXIgbWVzc2FnZSwgZm9yIGV4YW1wbGUpLg0KDQpUaGlzIHByb3Bv c2FsIHNob3VsZCBlbmFibGUgYSByYWRpY2FsIHNpbXBsaWZpY2F0aW9uIG9mIHRoZSBTZWNvbmRh cnkgQ2VydGlmaWNhdGUgQXV0aGVudGljYXRpb24gaW4gSFRUUC8yIHByb3Bvc2FsIChodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmlzaG9wLWh0dHBiaXMtaHR0cDItYWRkaXRpb25h bC1jZXJ0cy0wMSksIGFuZCBzaG91bGQgZ2VuZXJhbGx5IGJlIGEgdXNlZnVsIHRvb2wgZm9yIGJp bmRpbmcgYSBjZXJ0aWZpY2F0ZSBvd25lcnNoaXAgcHJvb2YgdG8gYSBUTFMgY29ubmVjdGlvbi4N Ck5pY2sgU3VsbGl2YW4NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClRMUyBtYWlsaW5nIGxpc3QNClRMU0BpZXRmLm9yZzxtYWlsdG86VExTQGlldGYu b3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0K --_000_BN3PR0301MB083670BEC8B1B0B40D532D8C8CA10BN3PR0301MB0836_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4ubTE3MTUxNjM4NDQ4NTQ5NDU0ODJpbmJveC1pbmJveC1sZw0KCXttc28tc3R5bGUtbmFtZTpt XzE3MTUxNjM4NDQ4NTQ5NDU0ODJpbmJveC1pbmJveC1sZzt9DQpzcGFuLmhvZW56Yg0KCXttc28t c3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29s b3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt b25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQi IHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0 IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFk Pg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+WWVzLCB0aGlzIGxpbmUgaGFzIGNvbmZ1c2VkIG1lIGFzIHdlbGwuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PkNoZWVycyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+QW5kcmVpPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9y Z10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+V2lsbGlhbSBXaHl0ZTxicj4NCjxiPlNlbnQ6PC9iPiBU dWVzZGF5LCBOb3ZlbWJlciAxLCAyMDE2IDE6NDIgQU08YnI+DQo8Yj5Ubzo8L2I+IE5pY2sgU3Vs bGl2YW4gJmx0O25pY2hvbGFzLnN1bGxpdmFuQGdtYWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+ IHRsc0BpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gZHJhZnQtc3VsbGl2 YW4tdGxzLWV4cG9ydGVkLWF1dGhlbnRpY2F0b3ItMDA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JJ20gY29uZnVzZWQgYnkgdGhlIGxpbmUgJnF1b3Q7VGhlc2UgbWVzc2Fn ZXMgYXJlIG5vdCBlbmNyeXB0ZWQmcXVvdDssIGJlY2F1c2Ugb24gYSBwbGFpbiByZWFkaW5nIGl0 IGNvdWxkIG1lYW4gdGhhdCB0aGUgYXV0aGVudGljYXRvciBpcyBzZW50IG91dHNpZGUgdGhlIGVu Y3J5cHRlZCBUTFMgc2Vzc2lvbi4gVGhhdCB3b3VsZCBiZSBiYWQgYmVjYXVzZSBpdCB3b3VsZCBt ZWFuIHRoYXQgY2xpZW50cyB0aGF0IHdhbnRlZCB0bw0KIGF1dGhlbnRpY2F0ZSB0aGVtc2VsdmVz IGJ1dCB0byB0aGUgc2VydmVyIG9ubHkgd291bGRuJ3QgYmUgYWJsZSB0byB1c2UgdGhpcyBtZWNo YW5pc20uIEkgYXNzdW1lIHRoYXQncyBub3QgdGhlIGludGVudD8gSWYgdGhhdCBpc24ndCB0aGUg aW50ZW50LCBzdWdnZXN0IHJlcGhyYXNpbmcgYXMgJnF1b3Q7VGhlc2UgbWVzc2FnZXMgYXJlIG5v dCBlbmNyeXB0ZWQsIG90aGVyIHRoYW4gdGhlIGVuY3J5cHRpb24gcHJvdmlkZWQgb24gdHJhbnNt aXNzaW9uIGJ5DQogdGhlIFRMUyBzZXNzaW9uJnF1b3Q7LjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaWxsaWFtPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgT2N0IDMxLCAyMDE2IGF0 IDU6MjkgUE0sIE5pY2sgU3VsbGl2YW4gJmx0OzxhIGhyZWY9Im1haWx0bzpuaWNob2xhcy5zdWxs aXZhbkBnbWFpbC5jb20iIHRhcmdldD0iX2JsYW5rIj5uaWNob2xhcy5zdWxsaXZhbkBnbWFpbC5j b208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3Jk ZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAw aW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzIxMjEyMTtiYWNrZ3JvdW5kOndoaXRlIj4mbHQ7PC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zdWxsaXZhbi10bHMt ZXhwb3J0ZWQtYXV0aGVudGljYXRvci0wMCIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM3RTU3QzI7YmFja2dyb3VuZDp3aGl0ZSI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sLzwvc3Bhbj48L2E+PGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LXN1bGxpdmFuLXRscy1leHBvcnRlZC1hdXRoZW50aWNhdG9yLTAwIiB0YXJnZXQ9Il9ibGFu ayI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzdFNTdDMjtiYWNrZ3JvdW5kOndoaXRlIj5kcmFm dC1zdWxsaXZhbi10bHMtZXhwb3J0ZWQtYXV0aGVudGljYXRvci0wMCZndDs8L3NwYW4+PC9hPjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGp1c3QgcG9zdGVk IGEgbmV3IEludGVybmV0LURyYWZ0IGNhbGxlZCAmcXVvdDtFeHBvcnRlZCBBdXRoZW50aWNhdG9y cyBpbiBUTFMmcXVvdDsgaW4gdGhlIFRMUyB3b3JraW5nIGdyb3VwLjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbTox Mi4wcHQiPjxicj4NClRoZSBpbnRlbnQgb2YgdGhpcyBkcmFmdCBpcyB0byBlbmFibGUgcGFydGlj aXBhbnRzIGluIGEgVExTIGNvbm5lY3Rpb24gdG8gcHJvdmUgb3duZXJzaGlwIG9mIGFkZGl0aW9u YWwgY2VydGlmaWNhdGVzLiBUaGlzIGRpZmZlcnMgZnJvbSBwcmV2aW91cyBwcm9wb3NhbHMgKDxh IGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1zdWxsaXZhbi10bHMtcG9z dC1oYW5kc2hha2UtYXV0aC0wMCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC88c3BhbiBjbGFzcz0ibTE3MTUxNjM4NDQ4NTQ5NDU0ODJpbmJveC1pbmJveC1sZyI+ ZHJhZnQ8L3NwYW4+LXN1bGxpdmFuLXRscy1wb3N0LWhhbmRzaGFrZS1hdXRoLTAwPC9hPikNCiBp biB0aGF0IHRoZXNlIHByb29mcyBhcmUgbm90IHNlbnQgYXMgcGFydCBvZiB0aGUgVExTIGNvbm5l Y3Rpb24sIGJ1dCBpbnN0ZWFkIGV4cG9ydGVkIHNvIHRoYXQgdGhleSBjYW4gYmUgc2VudCBvdXQg b2YgYmFuZCAoYXMgcGFydCBvZiBhbiBhcHBsaWNhdGlvbiBsYXllciBtZXNzYWdlLCBmb3IgZXhh bXBsZSkuPGJyPg0KPGJyPg0KVGhpcyBwcm9wb3NhbCBzaG91bGQgZW5hYmxlIGEgcmFkaWNhbCBz aW1wbGlmaWNhdGlvbiBvZiB0aGUgU2Vjb25kYXJ5IENlcnRpZmljYXRlIEF1dGhlbnRpY2F0aW9u IGluIEhUVFAvMiBwcm9wb3NhbCAoPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWJpc2hvcC1odHRwYmlzLWh0dHAyLWFkZGl0aW9uYWwtY2VydHMtMDEiIHRhcmdldD0i X2JsYW5rIj5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtYmlzaG9wLWh0dHBiaXMt aHR0cDItYWRkaXRpb25hbC1jZXJ0cy0wMTwvYT4pLA0KIGFuZCBzaG91bGQgZ2VuZXJhbGx5IGJl IGEgdXNlZnVsIHRvb2wgZm9yIGJpbmRpbmcgYSBjZXJ0aWZpY2F0ZSBvd25lcnNoaXAgcHJvb2Yg dG8gYSBUTFMgY29ubmVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojODg4ODg4Ij5OaWNrIFN1bGxpdmFu PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48YnI+DQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NClRMUyBtYWlsaW5nIGxp c3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIj5UTFNAaWV0Zi5vcmc8L2E+PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rsczwv YT48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_BN3PR0301MB083670BEC8B1B0B40D532D8C8CA10BN3PR0301MB0836_-- From nobody Tue Nov 1 11:57:48 2016 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 C0DDB1298AD for ; Tue, 1 Nov 2016 11:57:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 gfJvt-X9YJE2 for ; Tue, 1 Nov 2016 11:57:45 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5651298B3 for ; Tue, 1 Nov 2016 11:57:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 12F2B12E3E; Tue, 1 Nov 2016 20:57:39 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id Yo4_4UznMecI; Tue, 1 Nov 2016 20:57:38 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id B98A321C; Tue, 1 Nov 2016 20:57:38 +0200 (EET) Date: Tue, 1 Nov 2016 20:57:36 +0200 From: Ilari Liusvaara To: William Whyte Message-ID: <20161101185736.GA25587@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 01 Nov 2016 18:57:48 -0000 On Tue, Nov 01, 2016 at 04:41:44AM -0400, William Whyte wrote: > I'm confused by the line "These messages are not encrypted", because on a > plain reading it could mean that the authenticator is sent outside the > encrypted TLS session. That would be bad because it would mean that clients > that wanted to authenticate themselves but to the server only wouldn't be > able to use this mechanism. I assume that's not the intent? If that isn't > the intent, suggest rephrasing as "These messages are not encrypted, other > than the encryption provided on transmission by the TLS session". What I think it means that the authenticator is not encrypted before handing it to the application for transport (most probably ultimately ending inside the TLS connection itself, which does encrypt it on the wire). Also, the message emitted is formatted as follows, right? - Byte 0x0B (CERTIFICATE code) - 3-byte length of Certificate message - Standard TLS 1.3 Certificate message payload - Byte 0x0F (CERTIFICATE_VERIFY code) - 3-byte length of CertificateVerify message - Standard TLS 1.3 CertificateVerify message payload - Byte 0x14 (FINISHED code) - 3-byte length of Finished message - Standard TLS 1.3 Finished message payload -Ilari From nobody Tue Nov 1 13:17:28 2016 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 941D21299DF for ; Tue, 1 Nov 2016 13:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=securityinnovation.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 j8sJS3Y2W7yg for ; Tue, 1 Nov 2016 13:17:25 -0700 (PDT) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 25CA01299E0 for ; Tue, 1 Nov 2016 13:17:25 -0700 (PDT) Received: by mail-vk0-x22f.google.com with SMTP id p9so37220102vkd.3 for ; Tue, 01 Nov 2016 13:17:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=securityinnovation.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eiMXEzNVZdgK6rD/bhjJUNvPz1I0gf1pR7beqbbJhGA=; b=EB/AKxM5VXZCxkvoSmezQz+fMmVZD5aATB8OjPrpxWncpwXeqbfq3402oU1YuT4M03 zZN4k6cyDgNV4QhGznM9Z5BNDKV8njPCm/A5vdRC3CJviRZjrH/4+sfiWPloVVSp6msx ksnWuLO5FZbzdZGQ8XQKyu+MeOYj/XllIEj5g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eiMXEzNVZdgK6rD/bhjJUNvPz1I0gf1pR7beqbbJhGA=; b=BYo0D0AmDA8y+TpPomcrrDd4BVBP9EdfPmnTS7XcScEL6gJSwJ0Kn8mUUTZxKaPN5N l4ss8h/PWukp4rjx+i3R3B0/MDTKpqqxAeKL7Bs0EHSDIyxDBywfrYsV0z7caTVI8q7W Cvz283Zg5xM/RhatQMU9agzLlE9UtBqmCbzClkEcPsX6grr2ElvcoqKIA8uWC9NxAHqW TelrF7vxUzHuUX9ebD1bia7hmRcVNUKlWk2bGcteE95RYPJzYNJ+3P5rGBH/TiAy6/vi Q5oxyb/E3IuvWo/4peodeToC9eEghxk+lGWOEsqJ+wJ3LADU8BKXtdkpv+i2qnXgU/9u QSbw== X-Gm-Message-State: ABUngvcnehoI06hbQ4cFp1A9OssmA/PJ22yvhuMx58YNDpqCRVuWE5MJ5JUcEmArn3nQAamjkPLxejwW7VFRI38f X-Received: by 10.31.76.134 with SMTP id z128mr29765812vka.59.1478031444095; Tue, 01 Nov 2016 13:17:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.80.122 with HTTP; Tue, 1 Nov 2016 13:17:13 -0700 (PDT) Received: by 10.176.80.122 with HTTP; Tue, 1 Nov 2016 13:17:13 -0700 (PDT) In-Reply-To: <20161101185736.GA25587@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161101185736.GA25587@LK-Perkele-V2.elisa-laajakaista.fi> From: William Whyte Date: Tue, 1 Nov 2016 16:17:13 -0400 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114dad503148a705404303b0 Archived-At: Cc: "" Subject: Re: [TLS] draft-sullivan-tls-exported-authenticator-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 01 Nov 2016 20:17:26 -0000 --001a114dad503148a705404303b0 Content-Type: text/plain; charset=UTF-8 That makes sense, but it'd be good to clarify the text. Thanks! William -- sent from my phone On Nov 1, 2016 11:57 AM, "Ilari Liusvaara" wrote: > On Tue, Nov 01, 2016 at 04:41:44AM -0400, William Whyte wrote: > > I'm confused by the line "These messages are not encrypted", because on a > > plain reading it could mean that the authenticator is sent outside the > > encrypted TLS session. That would be bad because it would mean that > clients > > that wanted to authenticate themselves but to the server only wouldn't be > > able to use this mechanism. I assume that's not the intent? If that isn't > > the intent, suggest rephrasing as "These messages are not encrypted, > other > > than the encryption provided on transmission by the TLS session". > > What I think it means that the authenticator is not encrypted before > handing it to the application for transport (most probably ultimately > ending inside the TLS connection itself, which does encrypt it on the > wire). > > > Also, the message emitted is formatted as follows, right? > > - Byte 0x0B (CERTIFICATE code) > - 3-byte length of Certificate message > - Standard TLS 1.3 Certificate message payload > - Byte 0x0F (CERTIFICATE_VERIFY code) > - 3-byte length of CertificateVerify message > - Standard TLS 1.3 CertificateVerify message payload > - Byte 0x14 (FINISHED code) > - 3-byte length of Finished message > - Standard TLS 1.3 Finished message payload > > > > > -Ilari > --001a114dad503148a705404303b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

That makes sense, but it'd be good to clarify the text. = Thanks!

William

-- sent from my phone


On Nov 1, 2016 11= :57 AM, "Ilari Liusvaara" <ilariliusvaara@welho.com> wrote:
On Tue, Nov 01, 2016 at 04:41:44AM -0400, Will= iam Whyte wrote:
> I'm confused by the line "These messages are not encrypted&qu= ot;, because on a
> plain reading it could mean that the authenticator is sent outside the=
> encrypted TLS session. That would be bad because it would mean that cl= ients
> that wanted to authenticate themselves but to the server only wouldn&#= 39;t be
> able to use this mechanism. I assume that's not the intent? If tha= t isn't
> the intent, suggest rephrasing as "These messages are not encrypt= ed, other
> than the encryption provided on transmission by the TLS session".=

What I think it means that the authenticator is not encrypted before
handing it to the application for transport (most probably ultimately
ending inside the TLS connection itself, which does encrypt it on the
wire).


Also, the message emitted is formatted as follows, right?

- Byte 0x0B (CERTIFICATE code)
- 3-byte length of Certificate message
- Standard TLS 1.3 Certificate message payload
- Byte 0x0F (CERTIFICATE_VERIFY code)
- 3-byte length of CertificateVerify message
- Standard TLS 1.3 CertificateVerify message payload
- Byte 0x14 (FINISHED code)
- 3-byte length of Finished message
- Standard TLS 1.3 Finished message payload




-Ilari
--001a114dad503148a705404303b0-- From nobody Tue Nov 1 21:30:44 2016 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 0EBF9129704 for ; Tue, 1 Nov 2016 21:30:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yg37pk8dlttB for ; Tue, 1 Nov 2016 21:30:40 -0700 (PDT) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 78D831293EE for ; Tue, 1 Nov 2016 21:30:40 -0700 (PDT) Received: by mail-qt0-x230.google.com with SMTP id c47so2491565qtc.2 for ; Tue, 01 Nov 2016 21:30:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xLzR2cMRT5q5kjz9IRiJ/cK/Z7i5dhjPaQ1N43kendc=; b=EaQhNrPI7ynscnj+gNrMNfdUtLWCdcArLXItRLQHFMcCcMZMcmiV+GRjvYS6ikR/xQ wf9baO9h6MXP7b5dkNeGJkLj4Ju4mQ/pszq8w/On4nHnGGG/g1HLVEC5yXw9oLe73rSL sDBBopuiteb4FeaG+Cv/no6SQFbG/AcWc3KWyKHaRaxZ7HgvzVa+5qd/Xl+8uiq5bwuv um95GshK91cCuPllM4yer+kvINJ+sNhV+j4G68LsyHtiexf3G54L2I2fpO2H4RQFyuHq F/UWEMcOfnRLPTDEzRRFu7k2ImcQkLo4npHDYVzjpam/xktSBuZyLlEq0RFjWfMozHkD qbDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xLzR2cMRT5q5kjz9IRiJ/cK/Z7i5dhjPaQ1N43kendc=; b=JQX2nFbR79tPwDB7IQ1aafSQhPTd/TZyFeOsJb2ALfifyT4PRMfq2FEprHY4/q2XL+ ZNSAK7iUtT/ckNLLuSAGg0q4ulXAKsjtY9JbzUmdPU+DI5CiHYd3R9BTlhX9yiEQCMoK SQpGix1ND+itoi9CHhpxACM6iteDd72x1XZNZ9naC0r3sh+CfL8OGJyYcw27lLgkJ1Wb YfrhdV8T3Tv667pz+4Fa2OeqZiGM/Ha+wvvLaNDWdVa0C99dCdIhX87/7x93MgEW7BgU /JG3w69Fq2OEX0Zrgl9i0NsQjPDWhha5EywYttJw3ckanpj9TdBDtI9X/CK5RSAdJYPG ug0A== X-Gm-Message-State: ABUngvc4xlX3VU+rcPHZgqIv6GPp21nG4rL25DqGlgaFNG1cSwkAjDLX47Z2VhXbMx3FvOK9lJdlduP3rIjVrA== X-Received: by 10.237.62.27 with SMTP id l27mr1469403qtf.34.1478061039565; Tue, 01 Nov 2016 21:30:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 1 Nov 2016 21:30:39 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 2 Nov 2016 15:30:39 +1100 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 04:30:42 -0000 On 2 November 2016 at 02:45, Watson Ladd wrote: > > That sounds good. The more we can turn bugs into ones that violate the > spec, the easier it will be to get them fixed. (Hopefully) failure to interoperate >> violate the spec I know that NSS rejects multiple HRRs. I expect that Boring does too (couldn't be bothered to check). That means you have to be even lazier than I am with interop testing to make this mistake :) From nobody Tue Nov 1 21:57:23 2016 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 E532D129436 for ; Tue, 1 Nov 2016 21:57:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHJ9f0Jt6PdS for ; Tue, 1 Nov 2016 21:57:20 -0700 (PDT) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 BAA441293E8 for ; Tue, 1 Nov 2016 21:57:20 -0700 (PDT) Received: by mail-ua0-x22d.google.com with SMTP id b35so3745269uaa.3 for ; Tue, 01 Nov 2016 21:57:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ESgi7DhkYkmkySN/tp6O3DjRAA6FY9McGO7VfCQmVcU=; b=ohILwAYDV9xvhxPQgtdwrcgAOKwEElt9658aBTSrQ5eaeM+eQ9jLOInMjbsb3XOsQu /ZL39rqpxQBr00Lge5eyxFcLNW5hnL6NG4N71uGPV3eYyWH9Y+S95gl4XHkufHx5ghUh aChAjvEYu5tEjxsYJXOIqXEapAIzVG6nS3Dw245ehWihhEc4cvUdlUBMaJ3XcMUf/ibn qgSlCeyOgdoBIhluvtV5Bs+l6DsLmFvxVd3mU6u3USWH5U6NHc5cqw8R8zmklnhCy2e6 ViEiYQurRm7wl0+8kuVG5P2zPy8d619EMZkqp74U6QQ9CEQBPe5SNqJXiRThoHcJ3qD7 jjVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ESgi7DhkYkmkySN/tp6O3DjRAA6FY9McGO7VfCQmVcU=; b=fTI4ojGOQt1lxE3N62gfKEjUeGF/tDd14i+PIQZEAiSLP4vvigMsTEC2AyEXCZ0p52 lQTLe4Dc1URL6m057rjeIO1j6HyQQ24x8FrHMxYDIT5HqMHO11l220hCwYcDBRCqTm6B gL4usuaIUX9om/mQJXRhEFaHNrRoFsDkMixUoRc9OrYUwzS+Ha4M3+3SfXdyaoEJmxjJ 3WckOxk8tIIv6twVKywcxMnfp0pzYrBypZp7MCd7cqc0+qnndJ/i5zw7uHNVglX0a5IG ljnxdlo/Q075GbV64HNN5pr3ChWmsnH4xXiz1saNmLSD97bXrsuS1f+GfI7CNOY0LHd+ RiPw== X-Gm-Message-State: ABUngvdVeBmYrxgGF6ZobsklfA/wBC+qpCm/xQIrCNe7oMZeT0YUuOV2mFU60jrAT40JKry2ypEU9NEg8Y2NNQ== X-Received: by 10.159.37.235 with SMTP id 98mr1046954uaf.115.1478062639756; Tue, 01 Nov 2016 21:57:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.68.135 with HTTP; Tue, 1 Nov 2016 21:57:19 -0700 (PDT) In-Reply-To: References: From: Watson Ladd Date: Tue, 1 Nov 2016 21:57:19 -0700 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 04:57:22 -0000 On Tue, Nov 1, 2016 at 9:30 PM, Martin Thomson wrote: > On 2 November 2016 at 02:45, Watson Ladd wrote: >> >> That sounds good. The more we can turn bugs into ones that violate the >> spec, the easier it will be to get them fixed. (Hopefully) > > failure to interoperate >> violate the spec > > I know that NSS rejects multiple HRRs. I expect that Boring does too > (couldn't be bothered to check). That means you have to be even > lazier than I am with interop testing to make this mistake :) A conforming client will not produce Client Hellos that trigger multiple HRRs: it will listen the first time. -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Tue Nov 1 23:04:32 2016 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 80FBB1294C0 for ; Tue, 1 Nov 2016 23:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4eW4yCk8LoXQ for ; Tue, 1 Nov 2016 23:04:30 -0700 (PDT) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 0EBBF1294BD for ; Tue, 1 Nov 2016 23:04:30 -0700 (PDT) Received: by mail-qk0-x22d.google.com with SMTP id o68so6619782qkf.3 for ; Tue, 01 Nov 2016 23:04:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f/UH/Klyqz5ZTC1TA15Is0/oHQi0SfEeChOYhAq4eTo=; b=IQJoWXZNN8Ngfx7ph9ao4YPMziTfP7pEZg7UY8cpv8Ah799ow/bEa5QzCl2N5qmoo2 D3buvp5ASmzWL0FRoAfwfwG2Qu47fL+TXTbYLt7tv+ANLMbD9lD2qo6nTwNi/n5QtFCc Gjh8QJqlcY0deMQ4CPibYIzgVXBY47FobJi7MnqHj14926lxK+FP2EJPR4KI+iBKYj/a DZBe9pFI9n9muk5CIV+WRG6+sAIMb9Jug/lwrgsyakICYjtfQ+cSYfJGjVy5DTbsrygt lwWUsd0qBEi+81ZLcycNb98+P0VcMTu98U6O6w/+YLFi3mRBnt6eDJu1r0T8Y1lB3sNu hpKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f/UH/Klyqz5ZTC1TA15Is0/oHQi0SfEeChOYhAq4eTo=; b=GJoZoaIHjqxREM8xJhH/fSydJVzbeFz0Vs/HcYxxnFwXenCFzeGcKbIrKZAUU4ljnG WL3GV78bIss3xHEfGTMAnYVhWCaUQpA2OK+9W3KjMIuHxNA3iScISCdQDJlGNEQfkp6x MLD9n7JHsTvd6+p6qEK9/L1hrXGzxuqejurxutM48Nyt8FEQvEfTQTRDY/WqWJTEgBK2 d/WR+jJfzF+G59v8FfTD36jzKNkqAhbkhSu1+ZCbVjKoMaQLiolJElwAVfAbhUfuoZAX 6svmnzOmg9DSioMD+EIXBwYu5ufhUdmy1AgEY4dhOgZVIs2YDc2EFUK3DIwP3QhLiOmJ UsNg== X-Gm-Message-State: ABUngvf0eHcvr8BQQhPYSTmcZDrO6DJs4YX2MaYLXrXwaU9MZvhu2nxRf5O0pqvRmqQBeG45sTxs2GyVmO1WMw== X-Received: by 10.55.158.199 with SMTP id h190mr1759431qke.202.1478066669198; Tue, 01 Nov 2016 23:04:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 1 Nov 2016 23:04:28 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Wed, 2 Nov 2016 17:04:28 +1100 Message-ID: To: Watson Ladd Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Comments on draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 02 Nov 2016 06:04:31 -0000 On 2 November 2016 at 15:57, Watson Ladd wrote: > A conforming client will not produce Client Hellos that trigger > multiple HRRs: it will listen the first time. Good point. And most clients will elicit none. I don't know how to force this one into a failure to interoperate without taking the approach Adam did with roughtime, and that's a tough call to make. From nobody Wed Nov 2 19:25:59 2016 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 365CB129577 for ; Wed, 2 Nov 2016 19:25:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 G1CFfgU-Wtim for ; Wed, 2 Nov 2016 19:25:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E19AF1298B3 for ; Wed, 2 Nov 2016 19:25:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B24F5BE56 for ; Thu, 3 Nov 2016 02:25:53 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mhJEE4zpB9gt for ; Thu, 3 Nov 2016 02:25:51 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 53EDDBE55 for ; Thu, 3 Nov 2016 02:25:51 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1478139951; bh=t+culwqucyAroZ0WkQ91cW3JzfKuzKOJ8rtrIWZITSY=; h=Subject:To:References:From:Date:In-Reply-To:From; b=vCuBQy2+utYa75HRWXRtwObdE2ma/rZvVn+gixAoYL1fNL/yzLx0xK3X1HPjhVAFn NhiANuMavz4c/gBoT7zxK3V6TAhFA23ZlGdRTJB1+8KTTjTwKy6gyvw2oNBmjGXWDF keLTZ4u204GqeisZD82TIgxd2ar+r1w/VwGt7dsI= To: "tls@ietf.org" References: <26941608-3cb4-2625-cd07-f2a1953fc394@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <21f3fe7d-1fe7-18c8-2e48-8bf4b54d3c0c@cs.tcd.ie> Date: Thu, 3 Nov 2016 02:25:51 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <26941608-3cb4-2625-cd07-f2a1953fc394@cs.tcd.ie> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070107020302000608080903" Archived-At: Subject: Re: [TLS] WG adoption of draft-sandj-tls-iana-registry-updates-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 02:25:58 -0000 This is a cryptographically signed message in MIME format. --------------ms070107020302000608080903 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Looks to me like this is fine to go ahead. So Sean and Joe, please submit a draft-ietf-tls- version of this I-D. Thanks, S On 22/10/16 15:30, Stephen Farrell wrote: >=20 > Hi all, >=20 > Sean and Joe wrote up this IANA registry draft as per > discussions at WG meetings and on the list. As they've > done the initial work, but are WG chairs, they wanted > me (as responsible AD) to call consensus for it. (They > wrote this up as finding authors for such fairly boring > stuff was hard - thank them for taking one for us all > when you see 'em:-) >=20 > Based on the earlier discussions and limited mails on > this draft, I do think there's consensus to adopt this > approach and that the text in the I-D [1] is a good > enough starting point for the WG. >=20 > If you think otherwise, please comment to the list in > the next week. >=20 > If you've questions about all this from a process-crap > POV, feel free to ask those on or off the list as you > think appropriate;-) >=20 > Note that if this is adopted as a WG item, the chairs > might decide to continue as editors or recruit someone > else. In the former case, I'm fine with doing the WGLC > stuff when this is ready (which it nearly is IMO, so > there may or may not be a need for new authors, depends > on what the WG think of the text I'd guess). >=20 > Cheers, > S. >=20 >=20 >=20 > [1] https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-0= 1 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms070107020302000608080903 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMDMw MjI1NTFaMC8GCSqGSIb3DQEJBDEiBCC0uJwNb1Q9i36F7+bgyorkEdj0X7TqIkslF6ElU2EX yDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQBazAgQtejIAJfsoxoMKsKqlxHvj4sCtKIYqlPWlTr20SWGBAMAMNK8 xd8r6oKnoYM3GfnufNVAg7ggRsp+sP6E/qWHhLR0bc5R5rLSryjLKANLkghqbQeY7Auws5L1 Dj1X5NU+7AYXuy4KLTytYgYFCMM5TOvQZ+dPaFJ8H7cUBxyyFfVdLDFcMrUxxTAiE0U2qacC nJM26wG2liVikW943KRSZqrEMLXVuWOUTE6DiizC+Wo49WbpzCkfRQ9MOYJOak1hXflYxjyp DprEmVlYkD/a48Yh+jpQsyVEvZh2AUptSHJgK7UyBhZg7vwdCWLwtcp39H41DpOq/DAdH/L6 AAAAAAAA --------------ms070107020302000608080903-- From nobody Wed Nov 2 22:01:08 2016 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 8DF3F12964E for ; Wed, 2 Nov 2016 22:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlj2oWsaRVBh for ; Wed, 2 Nov 2016 22:01:01 -0700 (PDT) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 2FCFD12940F for ; Wed, 2 Nov 2016 22:01:01 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id p16so21794474qta.0 for ; Wed, 02 Nov 2016 22:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=vS++/xWAweWYRmPj39WxE630XflURId/sJHmBIJiY5w=; b=eBkKol/vGWZrNX/DXOtAY33wclqL/st+ohaGG818UeqD4FsFNadenteMiyMp5jxyNL c9KsbLR3yLHmufFN6vEmvUD/YXfDXIywO8fI4Ck/xFTd9d9Z9Mc+QPnGr39vCqypp6CS 0gnYLKB1Uk0I1is+bWUABD6hl2WzklElzYlQtbwEASWBpLA6fp811iv0xSj1HIm91xya A7S+1oPxjO1VeTnnSM2gBv3FimouEPibmutrLe8ioZ9/3hgKNzAcg3Q5WD/vo5Mr0wav XNtaOEStbiq3hwmxjyegkNrLaFxRgAPG6RHzUY6jm/g4WNfHWVWP0X0IxA2TK7kNhmgs MVRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vS++/xWAweWYRmPj39WxE630XflURId/sJHmBIJiY5w=; b=AApawRDot5vGQC1oQQ41bQnZy6UHkf41elgzAvcGkKLYlySZnvw/xcvGR2JuM4l/H4 CE+Clao1sbI+R9PF7csNlEtXiTszO5ogRAchga6pWM7qIrOyaeRiqIRNrGzxbvwyNpDb tRuXg9O3xbAbRlrfIj1I8a5z+7Rd72b/jyDkZ7NaVIzA/UBu22ce4G0yvDnBt/ArRD8b gvSnH7YYAD9TTUdsA0OKJwGZxb51Z86oqhfSfPG4xdNik+vO7sjUhuY13UE3XhQ7vgtu MioJS2e/YdBl5pm/p5ZPwC1Hsg/XLzJT9cIFRU63TVFQ/LMBszyYk38+z+EEcHPdW+vQ 4tTQ== X-Gm-Message-State: ABUngvcaz2hRsBvQHJFGZ6x7Eekd+0KZA6NF/3r4SaEktWY2KfNQI4KnLFIt16FSug12e7IWnSKWXsZB3LKo3g== X-Received: by 10.237.62.27 with SMTP id l27mr6491339qtf.34.1478149260197; Wed, 02 Nov 2016 22:01:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Wed, 2 Nov 2016 22:00:59 -0700 (PDT) From: Martin Thomson Date: Thu, 3 Nov 2016 16:00:59 +1100 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Superficial review of draft-rescorla-tls-dtls13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 05:01:06 -0000 First of all, I think that this is pretty good work. I've implemented a version of DTLS 1.3 that you might assume based on the TLS 1.3 drafts and this is much better in several ways. The explicit ACK is nice, but I REALLY like the epoch management stuff, when I implemented it, it made things a lot easier all around. The big open item here is that the record format is grossly wasteful. Hannes and I have been discussing this offline and I have a sketch of a plan that should maintain compatibility but it will shave off 9 octets per record. We might be able to drop two more if we are willing to send more packets during the handshake. (Note that the draft seems to not do the content-type encryption, we'd fix that at the same time.) Nits: As in TLS, implementations MUST either abandon an association or re- key using a KeyUpdate message prior to allowing the sequence number to wrap. You also forbid use of KeyUpdate, which I think is the best answer. I wouldn't mark key_update as reserved though, lest IANA take that as an instruction somehow :) (Don't fix this, but why is fragment_length a uint24? You can't put that much data into a single record!) Figure 10 shows an arrow that spits off the middle of another line. That arrow isn't labelled. I can't see how to interpret that, nor conceive of what might belong there. Figure 10 should also switch from "last flight" to "ACK" (in two places). The change summary should reference TLS 1.3 for changes between TLS 1.2 and 1.3. It should talk about changes that are relevant to DTLS: the change of cookie handling, the change in record layout, the addition of an explicit ACK, and the handling of key updates. From nobody Thu Nov 3 07:31:59 2016 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 E9E73129A70 for ; Thu, 3 Nov 2016 07:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SVF-DH8VGJZX for ; Thu, 3 Nov 2016 07:31:55 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A9DB129A71 for ; Thu, 3 Nov 2016 07:31:29 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3t8nTW03CMz1J9S; Thu, 3 Nov 2016 15:31:27 +0100 (CET) X-purgate-ID: 152705::1478183487-00002B31-8339C362/0/0 X-purgate-size: 1984 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t8nTV3y1vzl09h; Thu, 3 Nov 2016 15:31:26 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 7B0F71A576; Thu, 3 Nov 2016 15:31:26 +0100 (CET) In-Reply-To: <20161029142228.GA27171@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara Date: Thu, 3 Nov 2016 15:31:26 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161103143126.7B0F71A576@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Thu, 03 Nov 2016 14:31:58 -0000 Ilari Liusvaara wrote: >>> >>> Hiding the types does have its benefits (and it is also used for >>> zero-overhead padding scheme). >> >> Nope, ZERO benefits. But it totally breaks the middleware >> _at_the_endpoints_! > > Also, things like this should have been discussed like year or two > ago. Right now it is too late for major changes like this without good > cryptographic justifications (which AFAICT don't exist). They WERE brought up back then, and several times in between. But the TLSv1.3 proposal has still not been fixed so far. Ignorance does not make problems go away. Instead, it means that one will have to fix it later. Since then, I've seen exactly ZERO rationale why the cleartext contenttype, which has existed through SSLv3->TLSv1.2 would be a problem. With the removal of renegotiation from TLSv1.3, it is even less of a problem to keep the contenttype in the clear. The removal of visibility of ContentType in TLSv1.3 will be a complete non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 for certain software architectures (including a lot of stuff we've been shipping for the last 5 years), because it is actively being used to signal state of the communication channel to the application and to *NOT* break application architecture that relies on (new) application data remaining visible on network sockets as "network readable" events. https://www.ietf.org/mail-archive/web/tls/current/msg13085.html https://www.ietf.org/mail-archive/web/tls/current/msg13106.html A similar issue exists for the visibility of Alert ContentTypes for efficiently detecting client-side connection closure. This has been described here: https://www.ietf.org/mail-archive/web/tls/current/msg21123.html The IETF technical leadership is supposed to prevent backwards-incompatible changes to be adopted and standardized that provide *ZERO* benefit, but severely impair interop and consumption. -Martin From nobody Thu Nov 3 10:20:01 2016 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 7D6D8129546 for ; Thu, 3 Nov 2016 10:19:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 b7FOLpMEy1FX for ; Thu, 3 Nov 2016 10:19:58 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id BFFF3129467 for ; Thu, 3 Nov 2016 10:19:57 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id E63AF4237A6; Thu, 3 Nov 2016 17:19:56 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id CEBC44237CE; Thu, 3 Nov 2016 17:19:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478193596; bh=zqNCihO0fdtgl40TpaeUEr4OO0YMk88TM6fH2+Z55Ac=; l=735; h=From:To:CC:Date:References:In-Reply-To:From; b=Wczq/MeOm6f0dPXiYvYNPe87Db061i1EqeAya1ACIupSmkQ8berXh+gy2Qohs9+H1 I914kKgiXhBEi54LYGDiL3pPiPccpPpyg2jO/HZtcMhCBkOsmnnz0h3/Y/TaxlKh2+ lbeIb/EgGIx4cBcOineHUwDXHucvshw4sD7FAAYg= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id C73381FC86; Thu, 3 Nov 2016 17:19:56 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 3 Nov 2016 10:19:56 -0700 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 3 Nov 2016 13:19:56 -0400 From: "Salz, Rich" To: "mrex@sap.com" , Ilari Liusvaara Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 Thread-Index: AQHSL/2+7HM9ClSQ40Wwf3PQxwdBMaC+S8KAgAAG0ACAACSwgIABS5EAgAfeKgD//+tGMA== Date: Thu, 3 Nov 2016 17:19:55 +0000 Message-ID: References: <20161029142228.GA27171@LK-Perkele-V2.elisa-laajakaista.fi> <20161103143126.7B0F71A576@ld9781.wdf.sap.corp> In-Reply-To: <20161103143126.7B0F71A576@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.37.0] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 17:19:59 -0000 > Since then, I've seen exactly ZERO rationale why the cleartext contenttyp= e, > which has existed through SSLv3->TLSv1.2 would be a problem. =20 Because it's kind of implied in the charter, about making as much private a= s possible. > years), because it is actively being used to signal state of the communic= ation > channel to the application and to *NOT* break application architecture th= at > relies on (new) application data remaining visible on network sockets as > "network readable" events. One app's data is another adversary's oracle. Or is it that "signals have = no morals"? /r$ -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz From nobody Thu Nov 3 10:30:09 2016 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 F3E891296DB for ; Thu, 3 Nov 2016 10:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4v4a41vatYd5 for ; Thu, 3 Nov 2016 10:30:06 -0700 (PDT) Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::235]) (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 829821296A1 for ; Thu, 3 Nov 2016 10:30:06 -0700 (PDT) Received: by mail-ua0-x235.google.com with SMTP id 12so45459438uas.2 for ; Thu, 03 Nov 2016 10:30:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Lgemjt5YBAd+u8mbWbYzeJDUwp/fK7unWbu1GeM0qGo=; b=TbXavzb7CElcMuaZjM60abBUmEMVFWomFfkEA4m10PbWJHsIFfA7+YdCwN8aaQI48f 8Hg4J+P2Osvkwh/xpLka48W4WUxfms7qz0XpKn6R90iqVWf87kBcMp0i3Y2sa+13Fuag 96LLnOaAer5GDjbaw1yifzwrDCkhWMxo7HCyRcYTt9a/MRq6y4sFB6aJs/nVDQWx0gnH Pxb63DJmrZKUkSvHiEv76dZwzJEjJOItEMFH6mmSZkv/KsUEXQwkWOtElN4LWHYx+PNr vGo266/7mJUSdcsP2Cli5tL3vdc+/R+bZsGZH9MUy6Ga9RLcPhO1Rvwn/7X/soy+gEP8 ewvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Lgemjt5YBAd+u8mbWbYzeJDUwp/fK7unWbu1GeM0qGo=; b=SUVhk4V6VJ93JePbPusGo71lH7e9BVWWGNTo9nFNuZ212xj2Q9sR3Vyy6ID9XXG32x jYgaCsYO6LhpQJ4WbRmkWV2bZEr8lcSLwFKqPVSgq1djtUf5ZCcsZvQaK3282ylj5Ou4 S2YoZtHigbBeKX5wXXHDS6rH1XKN2Sg8FHIDw7F/Yg3YMIZbjmqYPCHjZnxEQtY0IQNC 3iBGIHAoohdf7Mn96RYGgBY2T7phD4HtyjVhYx/bSU1+jTonxqogiZouDIAJeVekOyYr AE6jeqlVKYWoh3jiAp7nexgk0XaJuE+aRNdQ4xKH+6hFmGFsFrsNqOg0UwmUF5ro20t8 VQUg== X-Gm-Message-State: ABUngvflEuFkfHPq9eyNtNYfdr50ZhhRRf4O5/lV4IIM1/HO8gTHs2BL5cmf3Dfj14XbuiLWbPNnLQD2YTfIpQ== X-Received: by 10.159.37.235 with SMTP id 98mr5241721uaf.115.1478194205593; Thu, 03 Nov 2016 10:30:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.68.135 with HTTP; Thu, 3 Nov 2016 10:30:05 -0700 (PDT) In-Reply-To: <20161103143126.7B0F71A576@ld9781.wdf.sap.corp> References: <20161029142228.GA27171@LK-Perkele-V2.elisa-laajakaista.fi> <20161103143126.7B0F71A576@ld9781.wdf.sap.corp> From: Watson Ladd Date: Thu, 3 Nov 2016 10:30:05 -0700 Message-ID: To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 17:30:08 -0000 On Thu, Nov 3, 2016 at 7:31 AM, Martin Rex wrote: > Ilari Liusvaara wrote: >>>> >>>> Hiding the types does have its benefits (and it is also used for >>>> zero-overhead padding scheme). >>> >>> Nope, ZERO benefits. But it totally breaks the middleware >>> _at_the_endpoints_! >> >> Also, things like this should have been discussed like year or two >> ago. Right now it is too late for major changes like this without good >> cryptographic justifications (which AFAICT don't exist). > > They WERE brought up back then, and several times in between. > But the TLSv1.3 proposal has still not been fixed so far. > Ignorance does not make problems go away. Instead, it means that > one will have to fix it later. > > > Since then, I've seen exactly ZERO rationale why the cleartext contenttype, > which has existed through SSLv3->TLSv1.2 would be a problem. With the > removal of renegotiation from TLSv1.3, it is even less of a problem to > keep the contenttype in the clear. > > The removal of visibility of ContentType in TLSv1.3 will be a complete > non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 for certain > software architectures (including a lot of stuff we've been shipping for the > last 5 years), because it is actively being used to signal state of > the communication channel to the application and to *NOT* break application > architecture that relies on (new) application data remaining visible on > network sockets as "network readable" events. This I do not understand. I may make some technical errors in below, and would appreciate correction. I assume we have an application that is using poll() or select() or somesuch for nonblocking IO (maybe something fancier, but that is okay). This application grabs data from a ready connection, rams it through the TLS implementation, and then looks at what comes out. But reading from the connection clears the data available state! However, it's never the case that there is visible data absent a network read or write after the handshake. So what is the content type doing here? Does the application not call a TLS implementation provided state function to determine what state the connection is in? And if so why does the record layer need to know, as opposed to the handshake one? I'm not seeing why the above style implementation is impossible: Microsoft doesn't seem to think so and hasn't complained about this change. Sincerely, Watson Ladd From nobody Thu Nov 3 10:31:42 2016 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 0A01E1296DB for ; Thu, 3 Nov 2016 10:31:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv4DdSLcN9mA for ; Thu, 3 Nov 2016 10:31:39 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 20A92129AB4 for ; Thu, 3 Nov 2016 10:31:33 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id n67so1123959wme.1 for ; Thu, 03 Nov 2016 10:31:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2recxCWtM2ii5TY55+Wk02ajrb7VhIUphb8mhXbPb1A=; b=lvqk9fFsYwDXYzk0/DMn/RZpuw6fGf26VkFs+2cpjnm4Y4znPKmkFkVAn2cdRPGRwN NyGBvXpaz3iP/2HlxuMTurz5u+dmYi8tOA/FShklZWFE1PWZD+jnrLF8ovMgI5Nc7B4Q SzbxWvkLMQqv5bTz/lGa6agrzcGVoFfmLt6KR7EfdU9TBzU0pIwCaCfescyh1UV7oZbC lMWvy3kznCBjlMsWhaDECGKwj+ce+Qqi72iAxWHBcxsjt7BTaaQEr9kkzcGWcprbmBO+ GHkVu8ToGiNVzl6IfM8WQlge9dCwwfd25WieQeABM/tZ3Q1gadPVE3DxJmQ38AiRa/EM AS3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2recxCWtM2ii5TY55+Wk02ajrb7VhIUphb8mhXbPb1A=; b=nHT/n4RRJz8hllAlR6ZJ2FXsrm25rX83T1o1bf3ZI1ieApiefQXQEOqyaM8KTfG49B 6qsKJbt2wVOlVxpLv/WgKA4bKW3xNc3V8lPHuuhUDpDXH7f8hY6OdTnYk8+wN65Jygfq w1oMHVOoYKGphKiI/mWpGcwC7mTb0OZICD8Af8yqaLbqHKvfbdPPjKUsA+ERd2dmkWSi sAbxwYwL95G81EM8MXb3+g3mfBvB8rHKO2HGAaety2As76Xj1khcHqpoKyXE9zuH/xi7 b4qilK7fIv/mpCOnBMfUKyydvKDJDzzw+qJRSQqY5DVrimPu2dWnvI3J0kDfrmtz86r+ 2CeQ== X-Gm-Message-State: ABUngvd+8vbI5mJwJsjHIqOm0zMWsDrTDjL8JOApE4uBU6leH0UhSrK2h08KC+KuqOeg3Q== X-Received: by 10.28.215.6 with SMTP id o6mr8929535wmg.124.1478194291440; Thu, 03 Nov 2016 10:31:31 -0700 (PDT) Received: from [192.168.137.54] ([176.13.225.174]) by smtp.gmail.com with ESMTPSA id z6sm761636wjt.24.2016.11.03.10.31.30 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 10:31:30 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: <20161103143126.7B0F71A576@ld9781.wdf.sap.corp> Date: Thu, 3 Nov 2016 19:31:27 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161103143126.7B0F71A576@ld9781.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 17:31:41 -0000 On 3 Nov 2016, at 16:31, Martin Rex wrote: > Since then, I've seen exactly ZERO rationale why the cleartext = contenttype, > which has existed through SSLv3->TLSv1.2 would be a problem. With the > removal of renegotiation from TLSv1.3, it is even less of a problem to > keep the contenttype in the clear. Here=E2=80=99s some to get this to somewhat >0: Most TLS 1.2 connections will have a few handshake records, followed by = a couple of CCS records followed by a whole bunch of application = records, followed possibly by a single Alert. You only see more handshake records in two cases: 1. The client decided to re-negotiate. That is exceedingly rare. 2. The server decided a renegotiation is needed so it sent a = HelloRequest followed by a handshake. With visible content type, you can tell these two flows apart. What=E2=80=99= s more, there is rarely any reason to do #2 unless the server decided = that before accessing some resource, the client needs to present a = certificate. You can verify that by counting the number and adding up = the size of the handshake records. Having this happen usually means a = privileged resource and a privileged user. That=E2=80=99s quite a bit of = information to leak from a supposedly secure protocol. Yes, you won=E2=80=99= t know the user identity, but you=E2=80=99ll know enough to associate = privileged users with IP addresses, and you=E2=80=99ll know at what = times they accessed privileged resources as opposed to something like a = landing page. That=E2=80=99s meta-data, but it=E2=80=99s quite a lot of = meta-data. If we can avoid leaking that, why not? Yoav From nobody Thu Nov 3 10:42:01 2016 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 0AD86129446 for ; Thu, 3 Nov 2016 10:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lQJxDJV1zJcE for ; Thu, 3 Nov 2016 10:41:57 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 2EA7D129A7F for ; Thu, 3 Nov 2016 10:41:57 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id p190so1708422wmp.1 for ; Thu, 03 Nov 2016 10:41:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GmqY8e2jrOtPpSppSB7X/9GjEZz/zu5MH9HKOczO8Qc=; b=m/qr4tugKGUI9d0opWzyhpHm7omSt7/6PFNNgS3njFCV9+YSnKhH2kqdvNxH1vpO1K CvsQ0p/SYvPjMaWCwnFBtxRDIP6lFBn5uRMX9FfU2uehw0LL+wKhD8YW4bq57eEUKU5I DqgCeEeB0x1OjQZhoExbRbaAT/VBfnyOa12JIyVjGbg0NKRh8dPYVyQKIkPozyueeEIp dXQEtmUiAa3oJZcTrPpe3xh0kmE4pwRIFfa0ER86oAdc7HKcxYOlcqhYUzDrowQ5CQwS u/SEmghFsx2HIbH+BZcQxvt2FINy4zUVwrz67JPTBu+eX3B+iV3AA3lZONh9rv8HvqBM cTbg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GmqY8e2jrOtPpSppSB7X/9GjEZz/zu5MH9HKOczO8Qc=; b=eQMdLexFtYXEsh+xggjvsepDoXlHiNp3jBtGZIXJbScY50+7uI5iL9WA+1oEmGpq0o m05XBE54HQ6BtaMvvfuFSoMylmw6rgsITK3qvbamYYxlTdgclVOQrxO4f710tPhxDRQ+ gZrLD2jkpbDJncT+e63AgcFwbSum2m/PDpBT8ms2FP21U+jcQqM4xYdbi9mMuSAz8fPp TG9cb8NjwKerkPSTBBl4/YjgV7885mLWV5w0SBhKdUiWmqdkJqt4eCHMBZWtbkbJF130 tDT3NtpMjRlo7GrfVlxx1maT7DG02vG9O88tlmGqnLbSNAOlsuXiIS7mMBxGsqYzzGt9 //hA== X-Gm-Message-State: ABUngvf4VRAgEwsVW/FJ5JcgIejcGFyYviFZJNS26TgY1BHKk59OQRGXE5yArovN3djPLw== X-Received: by 10.28.143.7 with SMTP id r7mr3043082wmd.81.1478194915624; Thu, 03 Nov 2016 10:41:55 -0700 (PDT) Received: from [192.168.137.54] ([176.13.225.174]) by smtp.gmail.com with ESMTPSA id l19sm133115wmg.5.2016.11.03.10.41.51 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 10:41:54 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_9DF00D78-C2E3-400A-933E-3057E82DB1D2" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 3 Nov 2016 19:41:49 +0200 In-Reply-To: To: Watson Ladd References: <20161029142228.GA27171@LK-Perkele-V2.elisa-laajakaista.fi> <20161103143126.7B0F71A576@ld9781.wdf.sap.corp> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 17:42:00 -0000 --Apple-Mail=_9DF00D78-C2E3-400A-933E-3057E82DB1D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I don=E2=80=99t think this makes any difference in applications written = on commodity servers using regular socket APIs. It=E2=80=99s a kind of architecture that has a quick special purpose = processor that terminates the TCP and splits the incoming stream into = records. The application records are forwarded to a quick crypto = processor that decrypts the records and feeds them into the application. = Other types of records are forwarded to the handshake processor usually = implemented on general-purpose hardware with perhaps a cryptographic = accelerator for asymmetric operations. That performs the handshake and = feeds the key to the application processor. With the change in TLS 1.3, the TCP terminator can no longer tell the = records apart. That means that the crypto processor will have to take on = that duty. That=E2=80=99s a change in architecture that could require = new hardware as opposed to a firmware update for existing hardware. I tend to believe that if this had been such a big deal we would have = heard from more people, but I could be wrong. It=E2=80=99s clear to me = that the mid-sized content providers who are likely to use such = architectures are not yelling much. Yoav > On 3 Nov 2016, at 19:30, Watson Ladd wrote: >=20 > On Thu, Nov 3, 2016 at 7:31 AM, Martin Rex > wrote: >> Ilari Liusvaara wrote: >>>>>=20 >>>>> Hiding the types does have its benefits (and it is also used for >>>>> zero-overhead padding scheme). >>>>=20 >>>> Nope, ZERO benefits. But it totally breaks the middleware >>>> _at_the_endpoints_! >>>=20 >>> Also, things like this should have been discussed like year or two >>> ago. Right now it is too late for major changes like this without = good >>> cryptographic justifications (which AFAICT don't exist). >>=20 >> They WERE brought up back then, and several times in between. >> But the TLSv1.3 proposal has still not been fixed so far. >> Ignorance does not make problems go away. Instead, it means that >> one will have to fix it later. >>=20 >>=20 >> Since then, I've seen exactly ZERO rationale why the cleartext = contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. With = the >> removal of renegotiation from TLSv1.3, it is even less of a problem = to >> keep the contenttype in the clear. >>=20 >> The removal of visibility of ContentType in TLSv1.3 will be a = complete >> non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 for = certain >> software architectures (including a lot of stuff we've been shipping = for the >> last 5 years), because it is actively being used to signal state of >> the communication channel to the application and to *NOT* break = application >> architecture that relies on (new) application data remaining visible = on >> network sockets as "network readable" events. >=20 > This I do not understand. I may make some technical errors in below, > and would appreciate correction. >=20 > I assume we have an application that is using poll() or select() or > somesuch for nonblocking IO (maybe something fancier, but that is > okay). >=20 > This application grabs data from a ready connection, rams it through > the TLS implementation, and then looks at what comes out. But reading > from the connection clears the data available state! However, it's > never the case that there is visible data absent a network read or > write after the handshake. >=20 > So what is the content type doing here? Does the application not call > a TLS implementation provided state function to determine what state > the connection is in? And if so why does the record layer need to > know, as opposed to the handshake one? I'm not seeing why the above > style implementation is impossible: Microsoft doesn't seem to think so > and hasn't complained about this change. >=20 > Sincerely, > Watson Ladd >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls = --Apple-Mail=_9DF00D78-C2E3-400A-933E-3057E82DB1D2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 I don=E2=80=99t think this makes any difference in = applications written on commodity servers using regular socket APIs.

It=E2=80=99s a kind of = architecture that has a quick special purpose processor that terminates = the TCP and splits the incoming stream into records. The application = records are forwarded to a quick crypto processor that decrypts the = records and feeds them into the application. Other types of records are = forwarded to the handshake processor usually implemented on = general-purpose hardware with perhaps a cryptographic accelerator for = asymmetric operations. That performs the handshake and feeds the key to = the application processor.

With the change in TLS 1.3, the TCP terminator can no longer = tell the records apart. That means that the crypto processor will have = to take on that duty. That=E2=80=99s a change in architecture that could = require new hardware as opposed to a firmware update for existing = hardware.

I = tend to believe that if this had been such a big deal we would have = heard from more people, but I could be wrong. It=E2=80=99s clear to me = that the mid-sized content providers who are likely to use such = architectures are not yelling much.

Yoav

On = 3 Nov 2016, at 19:30, Watson Ladd <watsonbladd@gmail.com> wrote:

On Thu, Nov 3, 2016 at 7:31 AM, Martin Rex = <mrex@sap.com> wrote:
Ilari Liusvaara wrote:

Hiding = the types does have its benefits (and it is also used for
zero-overhead padding scheme).

Nope, ZERO benefits.  But it totally breaks the = middleware
_at_the_endpoints_!

Also, things like this should = have been discussed like year or two
ago. Right now it is = too late for major changes like this without good
cryptographic justifications (which AFAICT don't exist).

They WERE brought up back then, = and several times in between.
But the TLSv1.3 proposal has = still not been fixed so far.
Ignorance does not make = problems go away.  Instead, it means that
one will = have to fix it later.


Since = then, I've seen exactly ZERO rationale why the cleartext contenttype,
which has existed through SSLv3->TLSv1.2 would be a = problem.  With the
removal of renegotiation from = TLSv1.3, it is even less of a problem to
keep the = contenttype in the clear.

The removal of = visibility of ContentType in TLSv1.3 will be a complete
non-starter for TLSv1.3 as a drop-in replacement to TLSv1.2 = for certain
software architectures (including a lot of = stuff we've been shipping for the
last 5 years), because = it is actively being used to signal state of
the = communication channel to the application and to *NOT* break = application
architecture that relies on (new) application = data remaining visible on
network sockets as "network = readable" events.

This I do not understand. I may = make some technical errors in below,
and would appreciate = correction.

I assume we have an application that is using = poll() or select() or
somesuch for nonblocking IO (maybe = something fancier, but that is
okay).

This application grabs data from = a ready connection, rams it through
the TLS implementation, and then = looks at what comes out. But reading
from the connection clears the = data available state! However, it's
never the case that there is = visible data absent a network read or
write after the = handshake.

So what is the content type doing here? Does the = application not call
a TLS implementation provided state = function to determine what state
the connection is in? And if so = why does the record layer need to
know, as opposed to the = handshake one? I'm not seeing why the above
style implementation is impossible: Microsoft = doesn't seem to think so
and hasn't complained about this = change.

Sincerely,
Watson Ladd

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

= --Apple-Mail=_9DF00D78-C2E3-400A-933E-3057E82DB1D2-- From nobody Thu Nov 3 11:16:25 2016 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 887D8129AEA for ; Thu, 3 Nov 2016 11:16:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 I0YlR_foFAeO for ; Thu, 3 Nov 2016 11:16:19 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C07D129AC2 for ; Thu, 3 Nov 2016 11:15:50 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3t8tSN2n3Cz25yv; Thu, 3 Nov 2016 19:15:48 +0100 (CET) X-purgate-ID: 152705::1478196948-0000521C-59E07886/0/0 X-purgate-size: 1365 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t8tSM5Jvszkyyy; Thu, 3 Nov 2016 19:15:47 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B06D21A576; Thu, 3 Nov 2016 19:15:47 +0100 (CET) In-Reply-To: To: "Salz, Rich" Date: Thu, 3 Nov 2016 19:15:47 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161103181547.B06D21A576@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Thu, 03 Nov 2016 18:16:20 -0000 Salz, Rich wrote: >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. > > Because it's kind of implied in the charter, about making as much private as possible. > >> years), because it is actively being used to signal state of the communication >> channel to the application and to *NOT* break application architecture that >> relies on (new) application data remaining visible on network sockets as >> "network readable" events. > > One app's data is another adversary's oracle. > Or is it that "signals have no morals"? If you look at TLS records exchanged between two peers, and in particular if you perform a TLS handshake with same server yourself and compare, you can easily (heuristically) determine which TLS records of the original stream are hanshake records, and which are application data records. So there is exactly ZERO benefit of concealing the ContentTypes. But this concealing reliably breaks existing application middleware at the endpoints, which needs to reliably & quickly tell the difference between handshake&alert records and application data, so that it can leave application data records in the network buffer, so that the socket readable event remains visible for the event-based application logic. -Martin From nobody Thu Nov 3 11:20:50 2016 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 C6F0B129AEE for ; Thu, 3 Nov 2016 11:20:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 sAdUEtQ7_flO for ; Thu, 3 Nov 2016 11:20:47 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B64A1129AED for ; Thu, 3 Nov 2016 11:20:47 -0700 (PDT) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3t8tZ62V8Bz25yw; Thu, 3 Nov 2016 19:20:46 +0100 (CET) X-purgate-ID: 152705::1478197246-00003836-B793CF6F/0/0 X-purgate-size: 1600 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3t8tZ61smrzkyyn; Thu, 3 Nov 2016 19:20:46 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 34B541A576; Thu, 3 Nov 2016 19:20:46 +0100 (CET) In-Reply-To: To: Yoav Nir Date: Thu, 3 Nov 2016 19:20:46 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161103182046.34B541A576@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Thu, 03 Nov 2016 18:20:49 -0000 Yoav Nir wrote: > > On 3 Nov 2016, at 16:31, Martin Rex wrote: >> >> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >> which has existed through SSLv3->TLSv1.2 would be a problem. With the >> removal of renegotiation from TLSv1.3, it is even less of a problem to >> keep the contenttype in the clear. > > Here?s some to get this to somewhat >0: > > Most TLS 1.2 connections will have a few handshake records, > followed by a couple of CCS records followed by a whole bunch of > application records, followed possibly by a single Alert. > > You only see more handshake records in two cases: > 1. The client decided to re-negotiate. That is exceedingly rare. > 2. The server decided a renegotiation is needed > so it sent a HelloRequest followed by a handshake. > > With visible content type, you can tell these two flows apart. (a) so what? for those interested, one can tell such flows appart pretty reliably by traffic analysis. So there is exactly ZERO protection against bad guys, while breaking the good guys. (b) but TLSv1.2 remains unchanged, and this flow does not seem to exist in TLSv1.3, since renegotiation no longer exists in TLSv1.3. -- so why would we need a backwards-incompatible change in a protocol that protects something that no longer exists, but which severely breaks existing middleware, making it impossible to drop-in replace a TLSv1.2 implementation with a TLSv1.3 implementation that has this backwards-incompatibility. -Martin From nobody Thu Nov 3 11:33:21 2016 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 8F0E4129463 for ; Thu, 3 Nov 2016 11:33:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 RgVwtVaONG9s for ; Thu, 3 Nov 2016 11:33:17 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 767BD1200DF for ; Thu, 3 Nov 2016 11:33:17 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 6CE094334FC; Thu, 3 Nov 2016 18:33:16 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 4CBED433401; Thu, 3 Nov 2016 18:33:16 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478197996; bh=4m0xZ7QcjJPOQLNv+bRkA36388QWdg48reRP6e4+liM=; l=3949; h=To:References:Cc:From:Date:In-Reply-To:From; b=B9uofTPxPAYACdYc+C0FlK0lKL9nRBv4+JFW2jpZvISy/xbaxA9cmVEtc4L7koMU7 NeaOIhO21HzIJDqaElxjCFbzeHEA0byvea+pNllQDL1+R++sVx/XBgvj1PaxTWx4Xt AhUPKqsdObZC6DwQsYiKSiJRpLdd0mL59fNMy+R4= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1188D1FC88; Thu, 3 Nov 2016 18:33:15 +0000 (GMT) To: mrex@sap.com, "Salz, Rich" References: <20161103181547.B06D21A576@ld9781.wdf.sap.corp> From: Benjamin Kaduk X-Enigmail-Draft-Status: N1110 Message-ID: Date: Thu, 3 Nov 2016 13:33:15 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161103181547.B06D21A576@ld9781.wdf.sap.corp> Content-Type: multipart/alternative; boundary="------------878E34758B5DE5DAC98CCDDE" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 18:33:19 -0000 This is a multi-part message in MIME format. --------------878E34758B5DE5DAC98CCDDE Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 11/03/2016 01:15 PM, Martin Rex wrote: > Salz, Rich wrote: >>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >>> which has existed through SSLv3->TLSv1.2 would be a problem. >> Because it's kind of implied in the charter, about making as much private as possible. >> >>> years), because it is actively being used to signal state of the communication >>> channel to the application and to *NOT* break application architecture that >>> relies on (new) application data remaining visible on network sockets as >>> "network readable" events. >> One app's data is another adversary's oracle. >> Or is it that "signals have no morals"? > If you look at TLS records exchanged between two peers, > and in particular if you perform a TLS handshake with same server > yourself and compare, you can easily (heuristically) determine > which TLS records of the original stream are hanshake records, > and which are application data records. > > So there is exactly ZERO benefit of concealing the ContentTypes. > > Sorry, but that doesn't directly follow. With visible content type, an observer can *trivially* tell apart the two flows you mentioned in your next message. With current stacks' (lack of) padding and timing obfuscation, the observer can still tell the flows apart ... but you have a chance of writing a stack that prevents the observer from doing so. I don't think that "goes from 'impossible' to 'you have to write code'" can be construed as exactly zero benefit. -Ben --------------878E34758B5DE5DAC98CCDDE Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 11/03/2016 01:15 PM, Martin Rex wrote:
Salz, Rich wrote:

Since then, I've seen exactly ZERO rationale why the cleartext contenttype,
which has existed through SSLv3->TLSv1.2 would be a problem.  

Because it's kind of implied in the charter, about making as much private as possible.


years), because it is actively being used to signal state of the communication
channel to the application and to *NOT* break application architecture that
relies on (new) application data remaining visible on network sockets as
"network readable" events.

One app's data is another adversary's oracle.
Or is it that "signals have no morals"?

If you look at TLS records exchanged between two peers,
and in particular if you perform a TLS handshake with same server
yourself and compare, you can easily (heuristically) determine
which TLS records of the original stream are hanshake records,
and which are application data records.

So there is exactly ZERO benefit of concealing the ContentTypes.

Sorry, but that doesn't directly follow. 

With visible content type, an observer can *trivially* tell apart the two flows you mentioned in your next message.  With current stacks' (lack of) padding and timing obfuscation, the observer can still tell the flows apart ... but you have a chance of writing a stack that prevents the observer from doing so.  I don't think that "goes from 'impossible' to 'you have to write code'" can be construed as exactly zero benefit.

-Ben
--------------878E34758B5DE5DAC98CCDDE-- From nobody Thu Nov 3 11:38:42 2016 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 0E7ED129479 for ; Thu, 3 Nov 2016 11:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aTEN3E4F2EqE for ; Thu, 3 Nov 2016 11:38:39 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 85DD51294A5 for ; Thu, 3 Nov 2016 11:38:37 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id a197so5006869wmd.0 for ; Thu, 03 Nov 2016 11:38:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=GNJ85TEfBN5ksCAAI/yUWWI8Pr+9X94s9h9/NlOHKrg=; b=ooOjI81+1JGLbbEY4RtBeeBvU1QqsrPzQqMaeHpia31zfZATCYe71mTsuNHB8Qee+i sXRhCmyVTnhZVSqXhQNubxJTdDPwPk3txlcGunx5ylLnGlh3jeGSVnt4jbMUBPxB22Af MpZNZzCt2YS42lzxILuwB3SBfptEwp9CmX7TQs6vISiXOZjuzpsTSV30j33eV7syK6gL hUsO2Yo5Zb+GBYy4Fq2KeKwGCQWNdXkszYYfApB38WV2/dtH/xoO7EiVacBwycQdusBw 5yl+JcQstMoPY2kq8kbnGr5PPyAcWf1SXV1R3LBotXBN6WTm4SVK8jIwFmgcaOTNwYOD aB4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=GNJ85TEfBN5ksCAAI/yUWWI8Pr+9X94s9h9/NlOHKrg=; b=h0R7pbo3qva9t61lv8Smf03vHOOtphjBkZqe+LfqaxNgh/yA1/ZqBl0qL2okycIYBJ ayzjvIk9Sex0QVHAVjFAE2g5vmkpfkjqtcaRExCZsLjYBWtZ0V16SURGeCa/qc2lFfcf BFzG/EYlEpKzh7sh++NyEs/Qzyl27xfx1sni9OPgp7+OKXmOH7juoVO+sPAK0IsDYJfu Ts+oiWJ0kCoIvl8Ryx+5zR6+kfiP0PPduZKfotkMUBGM8YZwpS8z9gvH/CY0HQ56t4Xv +sHllSy9qr/bC0SAfXp0sS+IW5FNLJ8lKqOuX0QaoXSJ5D4SDWI67bEqwxQDODupI/Jx PERQ== X-Gm-Message-State: ABUngvdD8TVCn+yqQyY24K7KiFMUcS23b8JcBsDr1kn7o6weEMJE0F66Tx4cNrFzfVi54Q== X-Received: by 10.28.27.133 with SMTP id b127mr1397622wmb.59.1478198316079; Thu, 03 Nov 2016 11:38:36 -0700 (PDT) Received: from [192.168.1.13] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id e5sm373206wma.10.2016.11.03.11.38.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 03 Nov 2016 11:38:35 -0700 (PDT) From: Yoav Nir Message-Id: <735A85B6-DDCF-48FC-8EF8-F31D44762F74@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_212CBCE1-010B-468D-B7F3-B69D28ECE908" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Thu, 3 Nov 2016 20:38:32 +0200 In-Reply-To: <20161103182046.34B541A576@ld9781.wdf.sap.corp> To: mrex@sap.com References: <20161103182046.34B541A576@ld9781.wdf.sap.corp> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 18:38:41 -0000 --Apple-Mail=_212CBCE1-010B-468D-B7F3-B69D28ECE908 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 3 Nov 2016, at 20:20, Martin Rex wrote: >=20 > Yoav Nir wrote: >>=20 >> On 3 Nov 2016, at 16:31, Martin Rex wrote: >>>=20 >>> Since then, I've seen exactly ZERO rationale why the cleartext = contenttype, >>> which has existed through SSLv3->TLSv1.2 would be a problem. With = the >>> removal of renegotiation from TLSv1.3, it is even less of a problem = to >>> keep the contenttype in the clear. >>=20 >> Here?s some to get this to somewhat >0: >>=20 >> Most TLS 1.2 connections will have a few handshake records, >> followed by a couple of CCS records followed by a whole bunch of >> application records, followed possibly by a single Alert. >>=20 >> You only see more handshake records in two cases: >> 1. The client decided to re-negotiate. That is exceedingly rare. >> 2. The server decided a renegotiation is needed >> so it sent a HelloRequest followed by a handshake. >>=20 >> With visible content type, you can tell these two flows apart. >=20 > (a) so what? for those interested, one can tell such flows appart > pretty reliably by traffic analysis. So there is exactly ZERO > protection against bad guys, while breaking the good guys. There is if you pad the records to the size of application records. > (b) but TLSv1.2 remains unchanged, and this flow does not seem to > exist in TLSv1.3, since renegotiation no longer exists in TLSv1.3. Re-negoatiation doesn=E2=80=99t, but post-handshake client = authentication does: https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2 = > -- so why would we need a backwards-incompatible change in a > protocol that protects something that no longer exists, > but which severely breaks existing middleware, making it > impossible to drop-in replace a TLSv1.2 implementation with > a TLSv1.3 implementation that has this backwards-incompatibility. Can you elaborate on that middleware? Yoav --Apple-Mail=_212CBCE1-010B-468D-B7F3-B69D28ECE908 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 3 Nov 2016, at 20:20, Martin Rex <mrex@sap.com> = wrote:

Yoav Nir wrote:

On 3 Nov = 2016, at 16:31, Martin Rex <mrex@sap.com> wrote:

Since then, I've seen exactly = ZERO rationale why the cleartext contenttype,
which has = existed through SSLv3->TLSv1.2 would be a problem.  With the
removal of renegotiation from TLSv1.3, it is even less of a = problem to
keep the contenttype in the clear.

Here?s some to get this to = somewhat >0:

Most TLS 1.2 connections = will have a few handshake records,
followed by a couple of = CCS records followed by a whole bunch of
application = records, followed possibly by a single Alert.

You only see more handshake records in two cases:
  1. The client decided to re-negotiate. That is = exceedingly rare.
  2. The server decided a = renegotiation is needed
     so = it sent a HelloRequest followed by a handshake.

With visible content type, you can tell these two flows = apart.

(a) so what?  for those = interested, one can tell such flows appart
    pretty = reliably by traffic analysis.  So there is exactly ZERO
    protection against bad = guys, while breaking the good guys.

There is = if you pad the records to the size of application records.

(b) but TLSv1.2 remains unchanged, and this flow = does not seem to
    exist in TLSv1.3, = since renegotiation no longer exists in TLSv1.3.

Re-negoatiation = doesn=E2=80=99t, but post-handshake client authentication = does:

    -- so why would = we need a backwards-incompatible change in a
    protocol that protects = something that no longer exists,
    but = which severely breaks existing middleware, making it
    impossible to drop-in = replace a TLSv1.2 implementation with
    a = TLSv1.3 implementation that has this = backwards-incompatibility.

Can you elaborate on that middleware?

Yoav

= --Apple-Mail=_212CBCE1-010B-468D-B7F3-B69D28ECE908-- From nobody Thu Nov 3 12:02:17 2016 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 E2ABA12978B for ; Thu, 3 Nov 2016 12:02:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 LpoMM2D8hKGy for ; Thu, 3 Nov 2016 12:02:13 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 727A7129AB3 for ; Thu, 3 Nov 2016 12:01:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id AE4631602E; Thu, 3 Nov 2016 21:01:29 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id V6dDmY80X78X; Thu, 3 Nov 2016 21:01:28 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 702A521C; Thu, 3 Nov 2016 21:01:28 +0200 (EET) Date: Thu, 3 Nov 2016 21:01:26 +0200 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20161103190126.GA11294@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161103182046.34B541A576@ld9781.wdf.sap.corp> <735A85B6-DDCF-48FC-8EF8-F31D44762F74@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <735A85B6-DDCF-48FC-8EF8-F31D44762F74@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 03 Nov 2016 19:02:16 -0000 On Thu, Nov 03, 2016 at 08:38:32PM +0200, Yoav Nir wrote: > > > On 3 Nov 2016, at 20:20, Martin Rex wrote: > > > > -- so why would we need a backwards-incompatible change in a > > protocol that protects something that no longer exists, > > but which severely breaks existing middleware, making it > > impossible to drop-in replace a TLSv1.2 implementation with > > a TLSv1.3 implementation that has this backwards-incompatibility. > > Can you elaborate on that middleware? Also, what platform (Java? .NET? Linux?) does that middleware run on, and some base interfaces from standard library (or widespread extensions) it uses for its API... What I think I gathered from the description (and this sounds very bizarre): - Upon new data indication, the middleware peeks TLS header from the incoming data buffer. - If it is not appdata, it is read and handled. - If it appdata, the socket readable indication is passed to the application (what supports that without wrapping the socket???) which it then reads (and presumably passes for decryption). That sounds much more bizarre than the zerocopy APIs in btls (the TLS lib I am working on), and those are already pretty odd. -Ilari From nobody Fri Nov 4 05:36:05 2016 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 EAB1E1297BF for ; Fri, 4 Nov 2016 05:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 1VQTHetT1mTl for ; Fri, 4 Nov 2016 05:36:02 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (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 BC254129474 for ; Fri, 4 Nov 2016 05:36:02 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id x4so156904314oix.2 for ; Fri, 04 Nov 2016 05:36:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=uNTKGHhrH/FxsPtgcJLd/peEQr0elN12bG8uUwcDm8A=; b=FSISRsChFBmewgwD3ai0iyN64IEnIv9qXl48l5yAU6aHQVTiC1lL4zJLScyt6/I/Fl qAPQXf6J1fK3Z8r18AU9odbsoce96J2ULNMTIqbqUBekJ9K15bT75kEIufjB5bUXDIup sd3eLTS/Kg1/01RtPodpBQxIH/0ZY79E3whRM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=uNTKGHhrH/FxsPtgcJLd/peEQr0elN12bG8uUwcDm8A=; b=Geu1BwOilhRqasPoXfKunewd4HHWRWGgod8Sak80kjELYFKjKUDOOuddAImaLIF0LI FoG7IR1AGzAxy7z3hc6CNXuh6yX8jCmgvH7hySHpTz7YX+csbvsZ4b+I3y90VyJUVk6K orqIY71SNPh7KNeA1CRiObu8QdfrdNp4qrbD9nDxmdjD+ZztTVAg6hmp1qPppd7p4A8g rdIPn3OX2PxpbMICg1Fvafw+m1ZSfxceAep5O64tHaN1aKqhhtjONj8Rb/My9XEN5k0G MHDQ2dewOgV5FgWfVpI6gV/kGSoshctLJ4DIvZDcBs0sNMjO68TPtNmjdd8M/V+R+7cu Gw/Q== X-Gm-Message-State: ABUngve++b+litTL4XMpxkA+pMT8X40GByxfTkcCg9tXQLIuuTVKvYfwz80FTmORMMRTtg== X-Received: by 10.202.93.11 with SMTP id r11mr12533577oib.5.1478262961923; Fri, 04 Nov 2016 05:36:01 -0700 (PDT) Received: from [5.5.33.108] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id d143sm3734462oib.5.2016.11.04.05.36.00 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 04 Nov 2016 05:36:01 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <0627B64B-513E-49DD-8DC4-0B95A1DA824F@sn3rd.com> Date: Fri, 4 Nov 2016 08:35:57 -0400 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] IETF 97 - draft TLS agenda X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 04 Nov 2016 12:36:04 -0000 I=E2=80=99ve uploaded a draft agenda: https://www.ietf.org/proceedings/97/agenda/agenda-97-tls-00.txt I=E2=80=99ll post slides as I get them; I=E2=80=99ll take pdf, ppt/pptx, = and links to gSlides and the earlier I get them the better. spt From nobody Sun Nov 6 22:29:22 2016 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 1A24D1294F5 for ; Sun, 6 Nov 2016 22:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3PMFhgRgNJm for ; Sun, 6 Nov 2016 22:29:19 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 A5FC7129515 for ; Sun, 6 Nov 2016 22:29:19 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id n204so154563079qke.2 for ; Sun, 06 Nov 2016 22:29:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=FosTUHspMLjTKayRf/RSk6yDKJ5zXPfzQ4ys4XElrrk=; b=Naw5J6cMJZ0lGqCoQUHbq9R5eOw+2zeBIx1mbY7Ge+zGVxZQVzzCZd+PUdv2SGc4cL EqiPnkZUWnVkHsfs1GSu969YTZBUY79xj6h3ygEB0Q0xv3iUZ20n1yKH6HU3/aqMJNQG UFpJgw9nD+ZdBNckywBrpFPCuICV9GD/hrCBo5Nr9X1LNSPeHN369lDmXOjDmOhv7RRy GODgxBxa4rxFeeUWiB8hHp9U2ET9jxjX7rHTm9xbjQRHa9Xw5oslXkRj5DvHAyqGwQVL gZfCJi/s+XeNRg8BX2XS1LtPQzqOizfldLiYCjH/ZO8UgVmq93SS+focSn1vCmo53p0h PEiw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FosTUHspMLjTKayRf/RSk6yDKJ5zXPfzQ4ys4XElrrk=; b=CyvasBoGNXrVQGgrklkQrOg+HmhpIAMz9XU4cTfr8vGHSNajH0XBfauMWeBc1MK/u0 OIpBhdAhA19JAsbRGkqwtVWQ6w2Gb/0RiCmjGMhh6YUt1IQ1H65HkqFrdnWMgF9TGFh/ IhVW/17TTNJN2q54r38QPUhFT6thhMVpEXI/bPJPrcun2SehO3CMCUUetyga8I6zq9ZR +hPlvLzVH8nbxso82pEXkA9QEy+1t+HhsCJzW9H57i6r0gyNeJdBeZlYRcWMNlmLsfNp LIfKuP3TvFbZdurGNvMwW0BLJ68td3Yli4LT6z9M1L2JVCgtojK8Y7vILBwyMbg5lzYc 0X8Q== X-Gm-Message-State: ABUngve5+ZvouOUrCmUQK0cCK96cYzb+9hnRf1jVPmaLB9bqLJA3tuQuJxip/tOerMnZpqerI8FCQHWubGoTlA== X-Received: by 10.55.184.68 with SMTP id i65mr5488199qkf.5.1478500158787; Sun, 06 Nov 2016 22:29:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 6 Nov 2016 22:29:18 -0800 (PST) From: Martin Thomson Date: Mon, 7 Nov 2016 17:29:18 +1100 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] draft-sandj-tls-iana-registry-updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 07 Nov 2016 06:29:21 -0000 I have reviewed this document. Other than some editorial stuff, which I have thrown into a PR, I think that this is good. From nobody Mon Nov 7 14:02:39 2016 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 6BD9B1299B5 for ; Mon, 7 Nov 2016 14:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 zB9gT2HyVG40 for ; Mon, 7 Nov 2016 14:02:36 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 D22DB1299B2 for ; Mon, 7 Nov 2016 14:02:35 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id q124so52580294itd.1 for ; Mon, 07 Nov 2016 14:02:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jUrlhw2xCwxJICxBW3Bjxal9ZwgoVaS1J5CZFCYB6ck=; b=Vk9GYU1Q8cXDQoaVKTHidfb9BWJljv4SINrApbxQGF7aIEXG68uGL8JoWLHSX57WrI Ua2M0CWEBrc0+yDo7SJjyoUOmwo/4xxQ9BezHB0RXZee9HC1IGoC24WYwUChLHTdEcEy 8dAxfXdaQElv5CK3aQA2562CzVBHJbJufhiz8D1NYNijJC95DIaKjLq+LxCnChfqB3TO MG3T6AliyKiqiVgjhhwgyDhj1nQIf2f5VNrKbS4jMAn5BXZxtKKXQl4Z1F9O+i9Volrc mKMJWS9MuIxWAtG8UU/7VTRtqAW2hRKHV3KhyILhaWxe4Whvi/8AvLaCDnFg0z3kr27D aznw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jUrlhw2xCwxJICxBW3Bjxal9ZwgoVaS1J5CZFCYB6ck=; b=aeQqyFhPZq4UqmXjTRahbDJcYU2T0Ml9hyVssxCdrABhdFJwK9GNbrpAw9ZXSg1qht vKyld1DPlK2hOY1Rbv1GDtk4txnxnBinJ+3pSqu0JvJlzVVU4rRMN3sKu/CXXqwJbW7N jiWvUsdpQEphxyFaDZEsrZgp/t1GkeyEnBe1kMNaRzCAhDKACJABTVvyb7lxdQ25xJuz WMeQ2QHTReSzD6wArFFb7God2eGiArVw8TQhYuU7LrvYOnnOWMZnCTBqV++HTwjmU/9Z GEcV2miSulp+zsfJQ71me0QSXfheBK390T0JQrl/ghTptqC46D1R/O7gppFQzsLRBnEy J4ZA== X-Gm-Message-State: ABUngveKqNL0FpoFbHP/nfr5YJftlTvNgounNYoZ/AUGgEUK7iWOsK6sPIKreMiwrFcq6Hxq3RNpH3j8QAKlSg== X-Received: by 10.36.52.129 with SMTP id z123mr6305576itz.117.1478556155253; Mon, 07 Nov 2016 14:02:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.85.83 with HTTP; Mon, 7 Nov 2016 14:02:34 -0800 (PST) In-Reply-To: <20161031223431.6j23de5gyqx6vpop@roeckx.be> References: <20161031185724.GA23357@LK-Perkele-V2.elisa-laajakaista.fi> <20161031223431.6j23de5gyqx6vpop@roeckx.be> From: Brian Smith Date: Mon, 7 Nov 2016 12:02:34 -1000 Message-ID: To: Kurt Roeckx Content-Type: multipart/alternative; boundary=001a113ad1506a23ab0540bd2eaf Archived-At: Cc: David Benjamin , "tls@ietf.org" Subject: Re: [TLS] supported_versions question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 07 Nov 2016 22:02:37 -0000 --001a113ad1506a23ab0540bd2eaf Content-Type: text/plain; charset=UTF-8 Kurt Roeckx wrote: > So I guess you're also saying that a server that implements TLS > 1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should > ignore the supported_versions even when it knows about it? > > I guess I have same questions but with only TLS 1.3 disabled, to > be sure when we need to look at it. >From the perspective of the application developer, if I've disabled TLS 1.3 then I'd rather not have any TLS 1.3 behavior implemented; I'd rather have the implementation behave the same as before it supported TLS 1.2, more-or-less. That means in particular that supported_versions should be ignored if TLS 1.3 and later have been disabled. Put another way, if TLS 1.2 is the maximum version the application has enabled, then the TLS 1.3 specification in total is irrelevant and only RFC 5246 (and perhaps earlier) apply, and those specifications don't specify supported_versions. Consider in particular that an application might want to disable (or avoid enabling) TLS 1.3 to avoid some problem (perhaps a security problem) with supported_versions processing. It would be bad to not have any way of disabling supported_versions processing, and it doesn't seem good from a usability standpoint to have a separate nob to control it. Cheers, Brian -- https://briansmith.org/ --001a113ad1506a23ab0540bd2eaf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Kurt= Roeckx <kurt@roeckx.be> wrote:
<= span style=3D"color:rgb(34,34,34)">So I guess you're also saying that a= server that implements TLS
1.1 to TLS 1.3, but disables TLS 1.2 and TLS 1.3 support should
ignore the supported_versions even when it knows about it?

I guess I have same questions but with only TLS 1.3 disabled, to
be sure when we need to look at it.

From th= e perspective of the application developer, if I've disabled TLS 1.3 th= en I'd rather not =C2=A0have any TLS 1.3 behavior implemented; I'd = rather have the implementation behave the same as before it supported TLS 1= .2, more-or-less. That means in particular that supported_versions should b= e ignored if TLS 1.3 and later have been disabled. Put another way, if TLS = 1.2 is the maximum version the application has enabled, then the TLS 1.3 sp= ecification in total is irrelevant and only RFC 5246 (and perhaps earlier) = apply, and those specifications don't specify supported_versions.
=

Consider in particular that an application might want t= o disable (or avoid enabling) TLS 1.3 to avoid some problem (perhaps a secu= rity problem) with supported_versions processing. It would be bad to not ha= ve any way of disabling supported_versions processing, and it doesn't s= eem good from a usability standpoint to have a separate nob to control it.<= /div>

Cheers,
Brian
--
<= /div>
--001a113ad1506a23ab0540bd2eaf-- From nobody Mon Nov 7 15:50:52 2016 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 8F7121296FF for ; Mon, 7 Nov 2016 15:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 Q1fU_6tP-8q8 for ; Mon, 7 Nov 2016 15:50:48 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7421296A6 for ; Mon, 7 Nov 2016 15:50:48 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3843C43346F; Mon, 7 Nov 2016 23:50:47 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 18074433467; Mon, 7 Nov 2016 23:50:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478562647; bh=MzXJxfQEy3xI5eiT8EKywUoI0yq8/8kccRGxXa7+phs=; l=3608; h=To:References:Cc:From:Date:In-Reply-To:From; b=ESnF07b+4PZ7cueENDLLXJ4F55TenZkJlxKx9nRU8x4PlTDRIXxwfb8WvXC+o83js dwDy0/q6Ywf5TGsjDFfCkVBb1W/7c790PN7agIOdJymudomq3BLDn8SDHSEbs2iw2/ HUx/s4U2eVYHk9y0M8gtSmFBtsvYSWVobsBoUGtg= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BB94E1FC90; Mon, 7 Nov 2016 23:50:46 +0000 (GMT) To: Eric Rescorla References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> From: Benjamin Kaduk Message-ID: Date: Mon, 7 Nov 2016 17:50:46 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4754098A842AE1458708CF1B" Archived-At: Cc: Matt Caswell , "tls@ietf.org" Subject: [TLS] (strict) decoding of legacy_record_version? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 07 Nov 2016 23:50:50 -0000 This is a multi-part message in MIME format. --------------4754098A842AE1458708CF1B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit (was Re: [TLS] PR#625: Change alert requirements) Digging up an old sub-thread... On 09/20/2016 08:03 AM, Eric Rescorla wrote: > > in Record Layer there's the following text: > > legacy_record_version : This value MUST be set to { 3, 1 } for all > records. This field is deprecated and MUST be ignored for all > purposes. > > in Record Layer Protection there's the following text: > > legacy_record_version : The legacy_record_version field is > identical to > TLSPlaintext.legacy_record_version and is always { 3, 1 }. > Note that the > handshake protocol including the ClientHello and ServerHello > messages > authenticates the protocol version, so this value is redundant. > > which doesn't say if the version can be ignored completely > (skipped while > parsing) or if it should be verified. > > > These are different fields. > There's still the question of whether the receiver should enforce 0x0301 in either/both cases. OpenSSL is implementing and seems to be reading the spec that it MUST be ignored (even though I guess strictly speaking that MUST only applies before record protection is engaged); if I'm doing my code survey correctly, Mint and NSS always enforce, and Boring only checks the first octet. Is there a reason to not do strict enforcement? -Ben --------------4754098A842AE1458708CF1B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit (was Re: [TLS] PR#625: Change alert requirements)

Digging up an old sub-thread...

On 09/20/2016 08:03 AM, Eric Rescorla wrote:
in Record Layer there's the following text:

    legacy_record_version : This value MUST be set to { 3, 1 } for all
    records. This field is deprecated and MUST be ignored for all purposes.

in Record Layer Protection there's the following text:

    legacy_record_version : The legacy_record_version field is identical to
    TLSPlaintext.legacy_record_version and is always { 3, 1 }. Note that the
    handshake protocol including the ClientHello and ServerHello messages
    authenticates the protocol version, so this value is redundant.

which doesn't say if the version can be ignored completely (skipped while
parsing) or if it should be verified.

These are different fields.


There's still the question of whether the receiver should enforce 0x0301 in either/both cases.
OpenSSL is implementing and seems to be reading the spec that it MUST be ignored (even though I guess strictly speaking that MUST only applies before record protection is engaged); if I'm doing my code survey correctly, Mint and NSS always enforce, and Boring only checks the first octet.

Is there a reason to not do strict enforcement?

-Ben
--------------4754098A842AE1458708CF1B-- From nobody Mon Nov 7 16:04:26 2016 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 DBB75129A72 for ; Mon, 7 Nov 2016 16:04:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 x4IqRpRmkGD2 for ; Mon, 7 Nov 2016 16:04:22 -0800 (PST) Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (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 E5EA0129620 for ; Mon, 7 Nov 2016 16:04:21 -0800 (PST) Received: by mail-wm0-x22b.google.com with SMTP id u144so32421924wmu.1 for ; Mon, 07 Nov 2016 16:04:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=qAPQs6/j+1cxBfvwBcRMF+qFAtil3du4I5U/w2c3sRo=; b=Xyy1GLz/3DYz6jenCSkwEBOR32ZmWVtJ/OCEQB7IQ9XyXVPNlI7tt73aLc/8P6HrFS 54zqaELMcKWHyo6/IvrBiLTPeuT2xCBgVKYKOC9iKEOC4KZCd/mnYeekwdSqXqU+DMCT VVYQZTedJx7W01rDBCEM5u+3SgRa8Bsm67df4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=qAPQs6/j+1cxBfvwBcRMF+qFAtil3du4I5U/w2c3sRo=; b=ksIwkbNrnsf0UMqAyQb2gJPzsJC5inXfSHDtzTXAGwtMRWe1/mHwdUOz020BUt5NKH zme63YpM7N39mr6a0FTcrwIpgmUZyhue887a/+LPrGLh/U0u8VbArnNkz6u3J7pJsB2G qPq8MdNDQGKX6bNWYaUM7JeThvnnVjyRIm1JQjrAbOU6u6Qs97e+8HWs8X0W78eNOzCD XUHM272zGNZOOuycA48ezpUr8RZXJjH4hMXvf6ILSmIqrqiMehP0S0Q8f/eOFoVifasw dqyD8cXsqhn6xvd06VwmI9Trzb/nk8KVo94iQS3DhK1IFnuO4BNNHlDkxMuKB0HYXHUb G6xg== X-Gm-Message-State: ABUngven5tBlvULTauXVaBzbtUH/61pdyNGcrhTgrzaXLdtdBFKu8nzFLz+Dbr+0pTGrQEQS8O8dkLps+VpQSCpz X-Received: by 10.28.18.194 with SMTP id 185mr8260186wms.124.1478563460284; Mon, 07 Nov 2016 16:04:20 -0800 (PST) MIME-Version: 1.0 References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> In-Reply-To: From: David Benjamin Date: Tue, 08 Nov 2016 00:04:09 +0000 Message-ID: To: Benjamin Kaduk , Eric Rescorla Content-Type: multipart/alternative; boundary=001a11469f6ad462bc0540bee1f9 Archived-At: Cc: Matt Caswell , "tls@ietf.org" Subject: Re: [TLS] (strict) decoding of legacy_record_version? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 00:04:24 -0000 --001a11469f6ad462bc0540bee1f9 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 7, 2016 at 6:50 PM Benjamin Kaduk wrote: (was Re: [TLS] PR#625: Change alert requirements) Digging up an old sub-thread... On 09/20/2016 08:03 AM, Eric Rescorla wrote: in Record Layer there's the following text: legacy_record_version : This value MUST be set to { 3, 1 } for all records. This field is deprecated and MUST be ignored for all purposes. in Record Layer Protection there's the following text: legacy_record_version : The legacy_record_version field is identical to TLSPlaintext.legacy_record_version and is always { 3, 1 }. Note that the handshake protocol including the ClientHello and ServerHello messages authenticates the protocol version, so this value is redundant. which doesn't say if the version can be ignored completely (skipped while parsing) or if it should be verified. These are different fields. There's still the question of whether the receiver should enforce 0x0301 in either/both cases. OpenSSL is implementing and seems to be reading the spec that it MUST be ignored (even though I guess strictly speaking that MUST only applies before record protection is engaged); if I'm doing my code survey correctly, Mint and NSS always enforce, and Boring only checks the first octet. Is there a reason to not do strict enforcement? Before you know the version, it is not safe to enforce. Prior versions of TLS did not pin down the value. (BoringSSL checks the first octet because OpenSSL did so, and it's vaguely nice to sanity-check on the first few bytes of data in the protocol.) Immediately after you know the version, enforcement is also problematic. Alerts sent in response to a ClientHello or ServerHello have somewhat ambiguous versions. One side may have decided the version is set while the other has not. Prior to 1.3, the record version needs to be set to the protocol version (or you break pre-1.3 enforcing implementations). But this means a receiver which enforces will fail to parse the alert. Not the end of the world, but weird. Once you've gotten as far as to switch to TLSCiphertext, I don't see a reason not to enforce. Keying on versions is problematic (which is why we avoided a transition to enforcement), but keying on whether the record is encrypted seems fine. I think it just didn't occur to us to base it on that. :-) David --001a11469f6ad462bc0540bee1f9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Mon, Nov 7, 2016 at= 6:50 PM Benjamin Kaduk <bkaduk@akamai.com> wrote:
=20 =20 =20
(was Re: [TLS] PR#625: Change alert requirement= s)

Digging up an old sub-thread...

On 09/20/2016 08:03 AM, Eric Rescorla wrote:
in Record Layer there's the following text:

=C2=A0 =C2=A0 legacy_record_version : This value MUST be set to { 3= , 1 } for all
=C2=A0 =C2=A0 records. This field is deprecated and MUST be ignored= for all purposes.

in Record Layer Protection there's the following text:

=C2=A0 =C2=A0 legacy_record_version : The legacy_record_version fie= ld is identical to
=C2=A0 =C2=A0 TLSPlaintext.legacy_record_version and is always { 3,= 1 }. Note that the
=C2=A0 =C2=A0 handshake protocol including the ClientHello and Serv= erHello messages
=C2=A0 =C2=A0 authenticates the protocol version, so this value is redundant.

which doesn't say if the version can be ignored completely (skipped while
parsing) or if it should be verified.

These are different fields.


There's still the question of whether the receiver should enforce 0x0301 in either/both cases.
OpenSSL is implementing and seems to be reading the spec that it MUST be ignored (even though I guess strictly speaking that MUST only applies before record protection is engaged); if I'm doing my code survey correctly, Mint and NSS always enforce, and Boring only checks the first octet.

Is there a reason to not do strict enforcement?
=

<= /div>
Before you know the version, it is not s= afe to enforce. Prior versions of TLS did not pin down the value. (BoringSS= L checks the first octet because OpenSSL did so, and it's vaguely nice = to sanity-check on the first few bytes of data in the protocol.)

= Immediately after you know the version, enforcement is also problematic. Al= erts sent in response to a ClientHello or ServerHello have somewhat ambiguo= us versions. One side may have decided the version is set while the other h= as not. Prior to 1.3, the record version needs to be set to the protocol ve= rsion (or you break pre-1.3 enforcing implementations). But this means a re= ceiver which enforces will fail to parse the alert. Not the end of the worl= d, but weird.

<= div class=3D"gmail_msg">Once you've gotten as far as to switch to TLSCi= phertext, I don't see a reason not to enforce. Keying on versions is pr= oblematic (which is why we avoided a transition to enforcement), but keying= on whether the record is encrypted seems fine. I think it just didn't = occur to us to base it on that. :-)

David
<= /div>
--001a11469f6ad462bc0540bee1f9-- From nobody Mon Nov 7 18:18:13 2016 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 D4B66129604 for ; Mon, 7 Nov 2016 18:18:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 efUSC77ObkTU for ; Mon, 7 Nov 2016 18:18:09 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 43F941295A1 for ; Mon, 7 Nov 2016 18:18:09 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id t125so162384124ywc.1 for ; Mon, 07 Nov 2016 18:18:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=p1zwyES1fGE5VRaFUUZpvxyZSFKNyYbs7Mo7Kp5xcqE=; b=abioCZ1atR/DsYG4XnlllvmDcreaWpaJZBqRfviKl0HfaGvt+ljjZUW1BMED8olmpo S6TsmdzTlI1r7wHp5pTAghptwlPWSThM/pRAyE5Xi4MGF2jDkGBOnA+QpYMCkcRR6PEv MsdOMMMfYxCpjQAfYpwbmQSctQ/5kd+pTY7TzMItwW/O+qWJD1oWZeicYK6WdNxOYrTU 5U0MyLuQfznbApM0AIo4qzkyEM9nEC8fK1bSBy7vyd97CEk2W463JP5IA35ndpKq8icH Zl28Cc7yG+baSkV8ACqL8zOuJbafgbv9GZ/gRy0m5BDenv2pvCzufmHGK0vnbDvFl1Up RlFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=p1zwyES1fGE5VRaFUUZpvxyZSFKNyYbs7Mo7Kp5xcqE=; b=Wp2/Zrt9G/OI3Sko/i6t5JQce0SE/HOHht1Lfb24b4rGpbc6flSK4X8LdEpV2KiHcs TOYqPlgXAWrZeQgQgA3dKeeIuoIggo8JssYTGgOxKs+hY/sV5VZIzT+HBVEZIzNZI1N0 21PsX3yge7Bc0Ax5YamBGS//00r6lgUNxF2Lbp3EWPpv1RVL/fWf0WMcFXeIADs42jwp s5GwaPhewDZoi2MWq7OsrP5KgiUSqedYkFJRps8i0nj3+jmrysVShNazFDDRnYQXCtAA /VXgWQGH6Cj5gRHKZBsvhBJHT/JPHWuvGChurjiUiGcbjxT93Wnbqjju/nU0VoBH89cL tG3w== X-Gm-Message-State: ABUngvfnd0A1uGomjNFo4qyhh5kfrNXADcofQb26Uhk3tVrjJtosJz3D2+JTB6zTTlq8WCEOyf7s0P/n3yI5+g== X-Received: by 10.129.125.215 with SMTP id y206mr8621826ywc.234.1478571488561; Mon, 07 Nov 2016 18:18:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 7 Nov 2016 18:17:27 -0800 (PST) In-Reply-To: References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> From: Eric Rescorla Date: Mon, 7 Nov 2016 18:17:27 -0800 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a11492dfa5a1fbc0540c0c020 Archived-At: Cc: Matt Caswell , "tls@ietf.org" Subject: Re: [TLS] (strict) decoding of legacy_record_version? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 02:18:11 -0000 --001a11492dfa5a1fbc0540c0c020 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 7, 2016 at 4:04 PM, David Benjamin wrote: > On Mon, Nov 7, 2016 at 6:50 PM Benjamin Kaduk wrote: > > (was Re: [TLS] PR#625: Change alert requirements) > > Digging up an old sub-thread... > > On 09/20/2016 08:03 AM, Eric Rescorla wrote: > > in Record Layer there's the following text: > > legacy_record_version : This value MUST be set to { 3, 1 } for all > records. This field is deprecated and MUST be ignored for all purposes. > > in Record Layer Protection there's the following text: > > legacy_record_version : The legacy_record_version field is identical to > TLSPlaintext.legacy_record_version and is always { 3, 1 }. Note that > the > handshake protocol including the ClientHello and ServerHello messages > authenticates the protocol version, so this value is redundant. > > which doesn't say if the version can be ignored completely (skipped while > parsing) or if it should be verified. > > > These are different fields. > > > There's still the question of whether the receiver should enforce 0x0301 > in either/both cases. > OpenSSL is implementing and seems to be reading the spec that it MUST be > ignored (even though I guess strictly speaking that MUST only applies > before record protection is engaged); if I'm doing my code survey > correctly, Mint and NSS always enforce, and Boring only checks the first > octet. > > Is there a reason to not do strict enforcement? > > > Before you know the version, it is not safe to enforce. Prior versions of > TLS did not pin down the value. (BoringSSL checks the first octet because > OpenSSL did so, and it's vaguely nice to sanity-check on the first few > bytes of data in the protocol.) > > Immediately after you know the version, enforcement is also problematic. > Alerts sent in response to a ClientHello or ServerHello have somewhat > ambiguous versions. One side may have decided the version is set while the > other has not. Prior to 1.3, the record version needs to be set to the > protocol version (or you break pre-1.3 enforcing implementations). But this > means a receiver which enforces will fail to parse the alert. Not the end > of the world, but weird. > > Once you've gotten as far as to switch to TLSCiphertext, I don't see a > reason not to enforce. Keying on versions is problematic (which is why we > avoided a transition to enforcement), but keying on whether the record is > encrypted seems fine. I think it just didn't occur to us to base it on > that. :-) > As you say, this is what NSS does. There's no legit reason for a TLS 1.3 encrypted record to have the wrong version number here, so I suggest changing the text. -Ekr > David > --001a11492dfa5a1fbc0540c0c020 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 7, 2016 at 4:04 PM, David Benjamin <davidben@chromium.= org> wrote:
On Mon, Nov 7, 2016 at 6:50 P= M Benjamin Kaduk <bkaduk@akamai.com> wrote:=
=20 =20 =20
(was Re: [TLS] PR#625: Ch= ange alert requirements)

Digging up an old sub-thread...

On 09/20/2016 08:= 03 AM, Eric Rescorla wrote:
in Rec= ord Layer there's the following text:

=C2=A0 =C2=A0 legacy_record_version : This value MUST be set to { 3= , 1 } for all
=C2=A0 =C2=A0 records. This field is deprecated and MUST be ignored= for all purposes.

in Record Layer Protection there's the following text:

=C2=A0 =C2=A0 legacy_record_version : The legacy_record_version fie= ld is identical to
=C2=A0 =C2=A0 TLSPlaintext.legacy_record_version and is always= { 3, 1 }. Note that the
=C2=A0 =C2=A0 handshake protocol including the ClientHello and Serv= erHello messages
=C2=A0 =C2=A0 authenticates the protocol version, so this value is redundant.

which doesn't say if the version can be ignored completely (skipped while
parsing) or if it should be verified.

These are different fi= elds.


There's still the question of whether the receiver should enforce 0x0301 in either/both cases.
OpenSSL is implementing and seems to be reading the spec that it MUST be ignored (even though I guess strictly speaking that MUST only applies before record protection is engaged); if I'm doing my code survey correctly, Mint and NSS always enforce, and Boring only checks the first octet.

Is there a reason to not do strict enforcement?

Before you know the version, it is not safe to enfo= rce. Prior versions of TLS did not pin down the value. (BoringSSL checks th= e first octet because OpenSSL did so, and it's vaguely nice to sanity-c= heck on the first few bytes of data in the protocol.)

Immediately after yo= u know the version, enforcement is also problematic. Alerts sent in respons= e to a ClientHello or ServerHello have somewhat ambiguous versions. One sid= e may have decided the version is set while the other has not. Prior to 1.3= , the record version needs to be set to the protocol version (or you break = pre-1.3 enforcing implementations). But this means a receiver which enforce= s will fail to parse the alert. Not the end of the world, but weird.
<= div class=3D"m_-4573309418650004305gmail_msg">
Once = you've gotten as far as to switch to TLSCiphertext, I don't see a r= eason not to enforce. Keying on versions is problematic (which is why we av= oided a transition to enforcement), but keying on whether the record is enc= rypted seems fine. I think it just didn't occur to us to base it on tha= t. :-)

As you say, = this is what NSS does. There's no legit reason for a TLS 1.3 encrypted = record to have the wrong version number here, so I suggest changing the tex= t.

-Ekr


David
<= /div>

--001a11492dfa5a1fbc0540c0c020-- From nobody Mon Nov 7 19:01:25 2016 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 8C74212948F for ; Mon, 7 Nov 2016 19:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 XDvcxWzusxBc for ; Mon, 7 Nov 2016 19:01:21 -0800 (PST) Received: from mail-it0-x229.google.com (mail-it0-x229.google.com [IPv6:2607:f8b0:4001:c0b::229]) (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 D610A129411 for ; Mon, 7 Nov 2016 19:01:20 -0800 (PST) Received: by mail-it0-x229.google.com with SMTP id e187so130654200itc.0 for ; Mon, 07 Nov 2016 19:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=o6uVGoDbjOsUZByA3SpQzxAts9zKqsQu3dpJbWevnd8=; b=GFDWdSroEcZIsGC8AEbxuuoSANGprzOCKiQePxJNHlVT3NSZrJFjjgVTiwp7gvC9ZL AEGZVc6GCveWBNL+J/4rRRaWs40SGXgeNfqm2pAUQ0A4sLZf/IIDlGc1Ha4VieHnwxig ZLy1xhGswFafBNYzygEEpJgD/xkDGROCvwbpv41g18sZC4TdDAt+GwkddcOcUsxqNyx7 ZpW4GXD2KdEKT0Huf0B4QkHaAxdv+e/aVGCpdYa+6/eR8pFKKGt5yLLrvIoBlzxiqIOQ bbxLszdsurctG6T6amU0kYZxB3Bwg1cExKs9SWtfW4Fwy+s3TMo4F6ZNpNKLHR+BB0HZ tpuw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=o6uVGoDbjOsUZByA3SpQzxAts9zKqsQu3dpJbWevnd8=; b=JBvd8hbFju8fWYTVTPGLziW1q0gdtjiAyklwY8WbHyoaCd/Z+roMorCfORW/4CMdGo +Ue93W3K5Xn57IeRz2n9YxQHgEMFMi8tUIOeFBfXOqoP87oEr0keitwwepO3tgIPFEkY UTQ2aNzjFKRykz+fivtDvAove+JvGhenoL0RFtab2beFCNvJF++28YMSRLaKfByQdfW3 5ryBG/bCP9gDMUOkNimfOsFZnb1vQGnhj5aWIpjiUOA6JtZyZzStT76SaMzHQujZnZkz hnatUQlWiniXRi6LYfKunJXyOck73jqE3b72IC0015ohqnWBat1q/dYFAmwSxU3R0GbC TlVg== X-Gm-Message-State: ABUngveHCAvkbGEUVo8Ogpx+zYeDEzmCIRWi1McuCe7S6buiD+kE8cBurDxbXZ0hnNS1hp42eLY3rZgEGdYQkw== X-Received: by 10.36.80.205 with SMTP id m196mr8534621itb.58.1478574079103; Mon, 07 Nov 2016 19:01:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.85.83 with HTTP; Mon, 7 Nov 2016 19:01:18 -0800 (PST) In-Reply-To: References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> From: Brian Smith Date: Mon, 7 Nov 2016 17:01:18 -1000 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a1140467ec282dc0540c15a6a Archived-At: Cc: Matt Caswell , "tls@ietf.org" Subject: Re: [TLS] (strict) decoding of legacy_record_version? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 03:01:22 -0000 --001a1140467ec282dc0540c15a6a Content-Type: text/plain; charset=UTF-8 David Benjamin wrote: > Once you've gotten as far as to switch to TLSCiphertext, I don't see a > reason not to enforce. Keying on versions is problematic (which is why we > avoided a transition to enforcement), but keying on whether the record is > encrypted seems fine. I think it just didn't occur to us to base it on > that. :-) > Since this field isn't included in the additional_data of the AEAD in TLS 1.3 any more, it isn't authenticated. That means an active MitM can use this to transport up to 2 bytes of information hop-to-hop if the receiver doesn't check it. That seems like a good reason to check it, and also to check TLSCiphertext.opaque_type is application_data. Assuming this is the reason, the reasoning should be explicitly called out because it is non-obvious. If that isn't a reason to do the check, then I don't think there's any reason to mandate that implementations do it. Cheers, Brian -- https://briansmith.org/ --001a1140467ec282dc0540c15a6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Davi= d Benjamin <davidben@chromium.org> wrote:
Once you've gotten as = far as to switch to TLSCiphertext, I don't see a reason not to enforce.= Keying on versions is problematic (which is why we avoided a transition to= enforcement), but keying on whether the record is encrypted seems fine. I = think it just didn't occur to us to base it on that. :-)

Since this field isn&#= 39;t included in the additional_data of the AEAD in TLS 1.3 any more, it is= n't authenticated. That means an active MitM can use this to transport = up to 2 bytes of information hop-to-hop if the receiver doesn't check i= t. That seems like a good reason to check it, and also to check TLSCipherte= xt.opaque_type is appl= ication_data. Assuming this is the reason, the reasoning should be explicit= ly called out because it is non-obvious.

If that isn't a reason to do the ch= eck, then I don't think there's any reason to mandate that implemen= tations do it.

Cheers,
Brian
--
--001a1140467ec282dc0540c15a6a-- From nobody Mon Nov 7 19:09:47 2016 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 54F75129490 for ; Mon, 7 Nov 2016 19:09:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gSh7VUSdiNo8 for ; Mon, 7 Nov 2016 19:09:42 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 781051294F2 for ; Mon, 7 Nov 2016 19:09:41 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id u205so175860630itc.0 for ; Mon, 07 Nov 2016 19:09:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=2f/v0lhV2DJbb/cHiaszABfNwvDmMkywCAYeFcHeHPM=; b=WqQ61kKmKZ4OE9z/Efi8yR52tz3meta8D8cn5hAO2UBo2rmim7gTcOGcaDMxq8co5O f4NSxGeT5bVsIgNAx20UQkQnS+9qWHWaT2VI0MtwLyCCGvlBDkLAxUmguej5iAEyvl/h +eeG70dAXXdGpZVCl6jcMY5M13Dg+6NwDTnOWNIvVX3kbRHLx/JU+gdQojPbIHrtR2aA z5kGlf2J0SVUvczC6rmjbQmXC631ACCGBAzX7YSUvi7Eg1Fsrt+xsY2BQpAq9i5K56oE P0c77/YDvbkIVS6UoSHt9JRrmUJRY+FIA2BZMs9hBjC6j44SVeHhIo5smYvvgkJA/B+Q 8rFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=2f/v0lhV2DJbb/cHiaszABfNwvDmMkywCAYeFcHeHPM=; b=a6+pZvdi/gWLhji4Z96YvYIf60jwYycw0aAp0Qsr4q2/YqPDb1Swe6SRHw3yaTA9RT KnADziDvIxJDgOayw8NcSjYAmbxtCSDk/KJkCFuBbXf0g5LuDyA8o2D7OSbelYd6YlaB Uoc1vPvQ7Vln7RHwVHacfnvA03KJ7jAsawLS9yPRE/gUZOR6ayxpwFNPM5A/3YzC7siP aTdBbp+3kqMbgHaoy53tK2hHe3fZsS4/lI4aCT/4KL9EC1NU6V8xY2q94jqQKhNoF92O dD11tO3VutT2U0pnG7iXvu7dI2t84Dyc7rhvanehhlcUcgBbRVmoEvbgIm88HULvGskY gfKw== X-Gm-Message-State: ABUngvfHseHup2sDW+pBa1qzYAeiRmdOjlREo3tDXGdfuja5hchGMX7UoalcYeCpBZkyUXDs63WR3hkiPn/UgQ== X-Received: by 10.107.18.39 with SMTP id a39mr10100590ioj.45.1478574580752; Mon, 07 Nov 2016 19:09:40 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Mon, 7 Nov 2016 19:09:40 -0800 (PST) In-Reply-To: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> From: Daniel Migault Date: Mon, 7 Nov 2016 22:09:40 -0500 X-Google-Sender-Auth: uBcZjmXqhl0FtHIHnUYLOFN3CTk Message-ID: To: John Mattsson Content-Type: multipart/alternative; boundary=001a113ff17ca8e80b0540c17810 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 03:09:46 -0000 --001a113ff17ca8e80b0540c17810 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Please find the text I propose. Let me know if you have any comment regarding the proposed text. Unless I receive comment on it, the text will be publish as soon as draft submission is possible. Yours, Daniel The cipher suites defined in this document are based on the AES-GCM and AES-CCM Authenticated Encryption with Associated Data (AEAD) algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, and AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and AEAD_AES_256_CCM_8 defined in [RFC6655]. For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF) with SHA-256 as the hash function SHALL be used and Clients and Servers MUST NOT negotiate curves of less than 255 bits. For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash function SHALL be used and Clients and Servers MUST NOT negotiate curves of less than 384 bits. TLS enable curve negotiation but not for code point. This makes restrictions on code points hard to implement. As a result Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a connection error of type insufficient_security(71) for TLS1.2 and TLS1.3. On Mon, Oct 24, 2016 at 11:22 AM, Daniel Migault < daniel.migault@ericsson.com> wrote: > Hi, > > My understanding is that the updated version should not introduce any > profile. Am I correct ? > > BR, > Daniel > > On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault < > daniel.migault@ericsson.com> wrote: > >> Hi, >> >> I am not very clear on how to update the text of the draft. The problem >> seems to me that code point restriction are hard to implement. As a resu= lt, >> the session is aborted with - insufficient_security(71) or equivalent - >> when the code point does not match the security strength. I am encline t= o >> think that we should also provide some profiles that achieve 128/256 bit >> security. These profiles may be described in this document or in another >> document more related to cryptographic recommendation. What would be the >> most appropriated way to move forward ? >> >> BR, >> Daniel >> >> >> >> On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson > > wrote: >> >>> Hi Dan, Sean, Nikos, >>> >>> First, let me state that I think requiring 128-bit key management for >>> AES-128 is quite reasonable. >>> >>> HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that appli= es >>> when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key >>> sizes >>> smaller than the lower limits as a connection error (Section 5.4.1 >>> ) of type >>> INADEQUATE_SECURITY." >>> >>> >>> I think this is a question for TLS in general, >>> draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decide= s >>> as the general way forward. Wether that is MAY/SHOULD/SHALL treat group= s >>> with insufficient security as an error. >>> >>> I think the real problem here are TLS libraries supporting 1024 MODP an= d >>> 160 ECC at all, support for these should have been removed before 2010. >>> Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2 >>> (i.e. WeakDH DieDieDie!!!). I think this is a great idea and much bette= r >>> than bundling it into a code-point assignment RFC. (My current plans fo= r >>> the next update of 3GPP=E2=80=99s TLS and DTLS profiles is simply to fo= rbid >>> support of anything weaker than 2048 MODP and 255-bit ECC). >>> >>> [0]. https://mailarchive.ietf.org/arch/msg/tls/4PZsc_Dy-aT299BYrl >>> BKvZs0BOQ >>> >>> >>> >>> Cheers, >>> John >>> >>> >>> On 11/07/16 22:26, "TLS on behalf of Dan Harkins" >> on >>> behalf of dharkins@lounge.org> wrote: >>> >>> > >>> > I'm glad I have to opportunity to make you happy Sean :-) >>> > >>> >On Mon, July 11, 2016 7:40 am, Sean Turner wrote: >>> >> I think I can take this bit: >>> >> >>> >> On Jul 10, 2016, at 06:51, Peter Dettman >>> >> >>> >> wrote: >>> >>> >>> >>> I'm also curious whether there is a precedent in other RFCs for an >>> >>> explicit minimum curve bits, or perhaps a de facto implementer's >>> rule? >>> >> >>> >> I'd be happy to be wrong here. but to my knowledge no there's not be= en >>> >> an explicit minimum for curve bits. There have however been similar >>> (at >>> >> least in my non-cryptographer mind) for RSA key sizes so if we wante= d >>> to >>> >> define an explicit minimum curve bits then we could. >>> > >>> > draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensuring >>> >the curves used provide commensurate strength with the ciphersuite >>> >negotiated. Section 10, "Implementation Considerations", says: >>> > >>> > It is RECOMMENDED that implementations take note of the strength >>> > estimates of particular groups and to select a ciphersuite providin= g >>> > commensurate security with its hash and encryption algorithms. A >>> > ciphersuite whose encryption algorithm has a keylength less than th= e >>> > strength estimate, or whose hash algorithm has a blocksize that is >>> > less than twice the strength estimate SHOULD NOT be used. >>> > >>> > And I would like to take this opportunity to remind everyone that >>> >the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 >>> >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resistant >>> >to dictionary attack and the former is not. >>> > >>> > regards, >>> > >>> > Dan. >>> > >>> > >>> > >>> >_______________________________________________ >>> >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 >>> >> >> > --001a113ff17ca8e80b0540c17810 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

Please find the text I pr= opose. Let me know if you have any comment regarding the proposed text. Unl= ess I receive comment on it, the text will be publish as soon as draft subm= ission is possible.

Yours,
Daniel

= =C2=A0=C2=A0 The cipher suites defined in this document are based on the AE= S-GCM
=C2=A0=C2=A0 and AES-CCM Authenticated Encryption with Associated = Data (AEAD)
=C2=A0=C2=A0 algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, = AEAD_AES_128_CCM, and
=C2=A0=C2=A0 AEAD_AES_256_CCM defined in [RFC5116]= , AEAD_AES_128_CCM_8 and
=C2=A0=C2=A0 AEAD_AES_256_CCM_8 defined in [RFC= 6655].

=C2=A0=C2=A0 For the AES-128 cipher suites, the TLS Pseudoran= dom Function (PRF)
=C2=A0=C2=A0 with SHA-256 as the hash function SHALL = be used and Clients and
=C2=A0=C2=A0 Servers MUST NOT negotiate curves o= f less than 255 bits.

=C2=A0=C2=A0 For the AES-256 cipher suites, th= e TLS PRF with SHA-384 as the hash
=C2=A0=C2=A0 function SHALL be used a= nd Clients and Servers MUST NOT negotiate
=C2=A0=C2=A0 curves of less th= an 384 bits.

=C2=A0=C2=A0 TLS enable curve negotiation but not for c= ode point.=C2=A0 This makes
=C2=A0=C2=A0 restrictions on code points har= d to implement.=C2=A0 As a result Endpoints
=C2=A0=C2=A0 MAY treat negot= iation of key sizes smaller than the lower limits as a
=C2=A0=C2=A0 conn= ection error of type insufficient_security(71) for TLS1.2 and
=C2=A0=C2= =A0 TLS1.3.





On Mon, Oct 24, 2016 at 11:22 AM, Daniel Mi= gault <daniel.migault@ericsson.com> wrote:
Hi,

My understanding is that the updated version should not introd= uce any profile. Am I correct ?

BR,
Daniel

On Mon, Oct 17, 2016 at 1:16 PM, Daniel Migault <daniel.migault@ericsson.com> wrote:
Hi,

I am no= t very clear on how to update the text of the draft. The problem seems to m= e that code point restriction are hard to implement. As a result, the sessi= on is aborted with - insufficient_security(71) or equivalent - when the cod= e point does not match the security strength. I am encline to think that we= should also provide some profiles that achieve 128/256 bit security. These= profiles may be described in this document or in another document more rel= ated to cryptographic recommendation. What would be the most appropriated w= ay to move forward ?

BR,
Daniel


On Sun, Oct 9, 2016 at 2:59 AM, John Mattsson &l= t;john.matt= sson@ericsson.com> wrote:
H= i Dan, Sean, Nikos,

First, let me state that I think requiring 128-bit key management for
AES-128 is quite reasonable.

HTTP/2 [RFC7540] also has some related text in Section 9.2.1 that applies when TLS is used for HTTP/2. "Endpoints MAY treat negotiation of key s= izes
smaller than the lower limits as a connection error (Section 5.4.1
<https://tools.ietf.org/html/rfc7540#sectio= n-5.4.1>) of type
INADEQUATE_SECURITY."


I think this is a question for TLS in general,
draft-ietf-tls-ecdhe-psk-aead should just follow what the TLS WG decides as the general way forward. Wether that is MAY/SHOULD/SHALL treat groups with insufficient security as an error.

I think the real problem here are TLS libraries supporting 1024 MODP and 160 ECC at all, support for these should have been removed before 2010.
Nikos [0] recommends a RCF forbidding weak elliptic curves from TLS 1.2
(i.e. WeakDH DieDieDie!!!). I think this is a great idea and much better than bundling it into a code-point assignment RFC. (My current plans for the next update of 3GPP=E2=80=99s TLS and DTLS profiles is simply to forbid=
support of anything weaker than 2048 MODP and 255-bit ECC).

[0]. https://mailarchive.ietf.o= rg/arch/msg/tls/4PZsc_Dy-aT299BYrlBKvZs0BOQ



Cheers,
John


On 11/07/16 22:26, "TLS on behalf of Dan Harkins" <tls-bounces@ietf.org on<= br>
behalf of dharkins@lounge.org> wrote:=

>
>=C2=A0 I'm glad I have to opportunity to make you happy Sean :-) >
>On Mon, July 11, 2016 7:40 am, Sean Turner wrote:
>> I think I can take this bit:
>>
>> On Jul 10, 2016, at 06:51, Peter Dettman
>><peter.dettman@bouncycastle.org>
>> wrote:
>>>
>>> I'm also curious whether there is a precedent in other RFC= s for an
>>> explicit minimum curve bits, or perhaps a de facto implementer= 's rule?
>>
>> I'd be happy to be wrong here. but to my knowledge no there= 9;s not been
>> an explicit minimum for curve bits.=C2=A0 There have however been = similar (at
>> least in my non-cryptographer mind) for RSA key sizes so if we wan= ted to
>> define an explicit minimum curve bits then we could.
>
>=C2=A0 draft-ietf-tls-pwd-07 includes a RECOMMENDED practice of ensurin= g
>the curves used provide commensurate strength with the ciphersuite
>negotiated. Section 10, "Implementation Considerations", says= :
>
>=C2=A0 =C2=A0It is RECOMMENDED that implementations take note of the st= rength
>=C2=A0 =C2=A0estimates of particular groups and to select a ciphersuite= providing
>=C2=A0 =C2=A0commensurate security with its hash and encryption algorit= hms.=C2=A0 A
>=C2=A0 =C2=A0ciphersuite whose encryption algorithm has a keylength les= s than the
>=C2=A0 =C2=A0strength estimate, or whose hash algorithm has a blocksize= that is
>=C2=A0 =C2=A0less than twice the strength estimate SHOULD NOT be used.<= br> >
>=C2=A0 And I would like to take this opportunity to remind everyone tha= t
>the only difference between TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256<= br> >and TLS_ECCPWD_WITH_AES_128_GCM_SHA256 is that the latter is resis= tant
>to dictionary attack and the former is not.
>
>=C2=A0 regards,
>
>=C2=A0 Dan.
>
>
>
>_______________________________________________
>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



--001a113ff17ca8e80b0540c17810-- From nobody Mon Nov 7 19:16:17 2016 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 10613129482 for ; Mon, 7 Nov 2016 19:16:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 aZY5cp0B_N_V for ; Mon, 7 Nov 2016 19:16:14 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 8857412948F for ; Mon, 7 Nov 2016 19:16:14 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id u205so176192080itc.0 for ; Mon, 07 Nov 2016 19:16:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=JbRUWzCy+k1/3RZKTHbd52gvaIRvt1Zo4ZjJw+1RRsE=; b=MEQ67R1XTS0LQmioI6/UfUsKBeLJTThYmahKF58SaDdcNrDb1Zpc9QX1ULd9vDeHcb irYuj9ZEuQd/qVBcTPwf6Bj+NrOBtDyp91Fg1KTTQhSzmF2tBAOa5xqxy5GfYJOm71NJ ZLkQrnNvSO6khMuPxGX4PcStkMj/kIoHBFxQSEj4Vp2XyHbDOSLhf/TjGQ7gGkn6BNSq wzdXZVYLsDvIsDhn2ksdYArgLMNnMioo2viIbJ7CWdKV7UX1m76EOkrc4zEw5BYv+74F YxX90KVGo/C8eVzaUWoAyFCAYcgaaPcjfpw19x6IEEYApFNVTfqmLsZngJzJsEm6RQ99 8xfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=JbRUWzCy+k1/3RZKTHbd52gvaIRvt1Zo4ZjJw+1RRsE=; b=k1KIoJnhYCGP4gyEfPuTdRR1d60bfpdoH3kXppe/WQUE+qPy80DLlwJypaiug3L1Qo 0Mt7uYco5lu6kuUiClR3alf3Tu0WkZkm/EMHcaumlhQxu67owpyynwRt+JySBD8HDUDE U63shSwyYQQyrlZk02yJiFSQRccGagvlW1kLvQadkIIXdaCWi9N2aaZHo0gEOIiSqWLZ /UKKuFNUPdo6mZp301WWCU7DglSatSjfhNhKRBkP/p+Hd76Arp9FknQcZBsbLk/o+n7M hYzOy/+tGQDBxSkfV58Ml4jStcuUzevewZEpnMDMkchmLEOx6/iG+wrRIHADfMKlKi41 F2rA== X-Gm-Message-State: ABUngvdtP/d8IlKGbXtdC0inkl0kHnlPXjuz+gjOdoeT/0qNiXF2Jiqxh9V6j58GDy5V1GBbhcqhukLkWnMlOA== X-Received: by 10.107.179.195 with SMTP id c186mr10504837iof.35.1478574973949; Mon, 07 Nov 2016 19:16:13 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Mon, 7 Nov 2016 19:16:13 -0800 (PST) In-Reply-To: <20161018163104.GA2405@LK-Perkele-V2.elisa-laajakaista.fi> References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> <20161018163104.GA2405@LK-Perkele-V2.elisa-laajakaista.fi> From: Daniel Migault Date: Mon, 7 Nov 2016 22:16:13 -0500 X-Google-Sender-Auth: Glg5ZmPi1T7V8vf2ye7_qKPHB7Q Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a1148483018b4fe0540c190c2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 03:16:16 -0000 --001a1148483018b4fe0540c190c2 Content-Type: text/plain; charset=UTF-8 Hi, The current draft is only considering TLS1.2. TLS1.3 is only mentioned for advocating AEAD. Do you think we should add text that details how to proceed with TLS1.3 ? If so what do you think of the following text ? Comments are welcome! Yours, Daniel The assigned code points are only expected to be used for TLS1.2. TLS1.3 does not follow the same name convention. Instead TLS1.3 cipher suites are designated according to the AEAD suite as well as the hash function used. The current combination of AEAD algorithms and Hash fucntion are already defined in TLS.1.3 so there is no need to add additional cipher suites for TLS1.3. Instead, in order to used the following ECDHE_PSK authentication method. TLS1.3 uses a combination of the "key_share" and "psk_key_exchange_modes" extentions. "psk_key_exchange_modes" extension sets its mode to psk_dhe_ke. The "key_share" extention contains a KeyShareEntry structure that carries the ECDHE parameters. On Tue, Oct 18, 2016 at 12:31 PM, Ilari Liusvaara wrote: > On Tue, Oct 18, 2016 at 04:22:59PM +0000, Xiaoyin Liu wrote: > > Why does this draft normatively depend on TLS 1.3, even if the > > cipher suites defined in this draft use the old syntax, which > > TLS 1.3 no longer uses? > > I don't see any reason why it would normatively depend. > > If it claims to be so, IMO that is a mistake and such reference should > be dropped (TLS 1.3 won't be able to use these anyway), or made in- > formative, in case the text wants to make a passing reference to TLS > 1.3. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1148483018b4fe0540c190c2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

The current draft is only= considering TLS1.2. TLS1.3 is only mentioned for advocating AEAD.

<= /div>Do you think we should add text that details how to proceed with TLS1.= 3 ? If so what do you think of the following text ?

Comme= nts are welcome!


Yours,
Daniel

=C2=A0=C2=A0 The assigned code points are only expected to be us= ed for TLS1.2.
=C2=A0=C2=A0 TLS1.3 does not follow the same name convent= ion.=C2=A0 Instead TLS1.3
=C2=A0=C2=A0 cipher suites are designated acco= rding to the AEAD suite as well as
=C2=A0=C2=A0 the hash function used.= =C2=A0 The current combination of AEAD algorithms
=C2=A0=C2=A0 and Hash = fucntion are already defined in TLS.1.3 so there is no need
=C2=A0=C2=A0= to add additional cipher suites for TLS1.3.

=C2=A0=C2=A0 Instead, i= n order to used the following ECDHE_PSK authentication
=C2=A0=C2=A0 meth= od.=C2=A0 TLS1.3 uses a combination of the "key_share" and
=C2= =A0=C2=A0 "psk_key_exchange_modes" extentions. "psk_key_exch= ange_modes"
=C2=A0=C2=A0 extension sets its mode to psk_dhe_ke.=C2= =A0 The "key_share" extention
=C2=A0=C2=A0 contains a KeyShare= Entry structure that carries the ECDHE parameters.


=

On Tue, Oct 18, 2= 016 at 12:31 PM, Ilari Liusvaara <ilariliusvaara@welho.com><= /span> wrote:
On Tue, Oc= t 18, 2016 at 04:22:59PM +0000, Xiaoyin Liu wrote:
> Why does this draft normatively depend on TLS 1.3, even if the
> cipher suites defined in this draft use the old syntax, which
> TLS 1.3 no longer uses?

I don't see any reason why it would normatively depend.

If it claims to be so, IMO that is a mistake and such reference should
be dropped (TLS 1.3 won't be able to use these anyway), or made in-
formative, in case the text wants to make a passing reference to TLS
1.3.


-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1148483018b4fe0540c190c2-- From nobody Mon Nov 7 19:50:40 2016 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 C0B2E1295DB for ; Mon, 7 Nov 2016 19:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uSWM6rYnFYv8 for ; Mon, 7 Nov 2016 19:50:37 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 F19181294B4 for ; Mon, 7 Nov 2016 19:50:36 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id x190so200929088qkb.0 for ; Mon, 07 Nov 2016 19:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=78bl3uV9wau+3mUmzf7nErT9v20RQaKpJrY7NmLqHNI=; b=h7yrMO6IPTCXku3bEw35M5CSv0sln2KqByhDsSrcUcyOWHPxWmsPZ2VhsMZLfhVgLp IhLRP4xoisrHf0N0XM8aAc4ALkIAeKyRxODQJaYKoUD0cDcCCHnycjnLJJ93sJHI8Lk7 9ZY8tAa0EkOUVplMXglfjKof+c0RuFdKr3D/dcYowUcXYwtiVnCSTYrWGwoYuyqh/Gkl M0oIFVunenZXPEUMoZZfTeEUhUDVCMYFfipAvV9Ybohx2TjGurWfSNMIvCMjf/RF0e41 soBGg9y4l8WTUSHAuFg+LoNK3BEj0eU2W6RVT8S2/dvnUJzdhMtsMMXv2tyxlKpuYEwX ghMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=78bl3uV9wau+3mUmzf7nErT9v20RQaKpJrY7NmLqHNI=; b=iqel5NocJWPQlaxaz0qJ0W7ERrEXsj+xOEyw6/oq+t8jHen9a6kC/EwAKqtTL0Q4vt MZE++ds0I640k9uZgNlJC+IggIVv9Uwk5S0J5z3zyGgmsxgs/B1tx8kmReoSiuOPSfKK xQzM6KClXxXZkyEsdbfmY89Y5YYAm2AZbM2PhkyfGSDl97oDMl48PV2Xfr/L0yyrY2dV 22wEY+5/OOgEEnsXtOASoBH47OwvCoyWL4oc9PPcYC9knN9RjzWQhh4AZnfYGQshEXlc UJ2xbbpGpJgRsOyrvdIGwSVCfshjM/Dg90h45F4IL/zJXGwCUO0YNggHbwO3XqViAGwe rnwA== X-Gm-Message-State: ABUngvcxmEwCQdV226OLQ+GDyy5SNEWW0sl98VwZpvtHhMJnB9Z6+RM40wv4kF5HC2B4gBctLhusGiiZg/AAyA== X-Received: by 10.55.12.2 with SMTP id 2mr9948781qkm.68.1478577036150; Mon, 07 Nov 2016 19:50:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 7 Nov 2016 19:50:35 -0800 (PST) In-Reply-To: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> From: Martin Thomson Date: Tue, 8 Nov 2016 14:50:35 +1100 Message-ID: To: Daniel Migault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 03:50:38 -0000 I don't understand this. I have no problems with a recommendation (i.e., SHOULD), but you will find that many implementations will not comply with these requirements when pushed. On 8 November 2016 at 14:09, Daniel Migault wrote: > The cipher suites defined in this document are based on the AES-GCM > and AES-CCM Authenticated Encryption with Associated Data (AEAD) > algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, and > AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and > AEAD_AES_256_CCM_8 defined in [RFC6655]. > > For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF) > with SHA-256 as the hash function SHALL be used and Clients and > Servers MUST NOT negotiate curves of less than 255 bits. This is two statements: 1. The PRF hash for these suites is SHA-256. That's not a requirement, you just define it, no 2119 language. 2. Using a weak key negotiation means that your key negotiation is the weak point. Here, my preference is to avoid stating a requirement, but that's only because it's very hard to get right. Otherwise, use a SHOULD and copy from HTTP/2: "When choosing these cipher suites, servers SHOULD select a key exchange that is at least 2048 bits for cipher suites that use ephemeral finite field Diffie-Hellman (DHE) [TLS12] and 224 bits for cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE) [RFC4492]." Getting into the exact number of bits is a bit self-defeating. 4Q isn't 255 bits. 25519 isn't either if you count them all. Both seem to be more than adequate in strength though. > For the AES-256 cipher suites, the TLS PRF with SHA-384 as the hash > function SHALL be used and Clients and Servers MUST NOT negotiate > curves of less than 384 bits. As above, but with bigger numbers. > TLS enable curve negotiation but not for code point. This makes > restrictions on code points hard to implement. As a result Endpoints > MAY treat negotiation of key sizes smaller than the lower limits as a > connection error of type insufficient_security(71) for TLS1.2 and > TLS1.3. Nits: 'enables'; there is a space between "TLS" and the version number. From nobody Mon Nov 7 19:53:14 2016 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 AC35F1296EF for ; Mon, 7 Nov 2016 19:53:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ip5xdMQltdac for ; Mon, 7 Nov 2016 19:53:12 -0800 (PST) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 632B012967C for ; Mon, 7 Nov 2016 19:53:12 -0800 (PST) Received: by mail-qk0-x235.google.com with SMTP id q130so202898803qke.1 for ; Mon, 07 Nov 2016 19:53:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NkqOOw5L+dbPaJYEwYLDhyPmSj9F/N7jLwdB/djV57k=; b=LKZJCB+zMEr2GcOQ6bznrCNdi4bBOSal8aDdpLzGphlEZB+rCvU/NTkhiw6WWLLXhX cdp/4sSSBQ+W0sQ4tN8AssnKhuDFQK0bNJGEEhiX2Ss6wMnRbZK5ZYsUOvUH2PZTECa1 TdJiUao2TLQKhxCtgjQAd4AX6zsVBDoc3s3mkmuaIiEsYo1mYhhwUrGdSN0FA6LVg48A EWc6jvJeVtxm2Z/DGcq2W2cj5VqbUcLSmmEQ1Dv5eIKcJdaOM+/coyVgAUNLMpliPcD8 6kLHi20Vt1vHkh4mTULkbn8C6wLvMsqxm2Ju3zA0DbIAo2WbumJAI9k/rdduJfzBqzn/ Wtfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NkqOOw5L+dbPaJYEwYLDhyPmSj9F/N7jLwdB/djV57k=; b=LRFqFVqzitNQZTT20f9pMWEqWSWF+biVJKcu35bOm4fGMHsOgGMCQv6oBJhWOrpMIf sQPszE/3KwFUkzg/4xDI4eCfFAZUznyjh5oALggH4PjM23fsZF/PE1ZQB2fL2U6YnJOY 8xB4PShNUVOPyzReLc+T+sTyECENOOnOX6cFf4uEyaD/dQvBpHJQLd+xltO/8JScuohp 8ysPQDCudzjklowdS7LYMtaZ0UFphd1ytd/hfYaFqtV+M5bKC8hS63anPeTL0xaf/cW1 oG1wSOylA0OyCP31iRKZsgtDOpiSaGjfNoBJ+XdP67Nuoy082Jq/XjzoR42CDRTDS8m+ vp2Q== X-Gm-Message-State: ABUngvdr8i3KRGFZpiR8cTHy2wyxMVJcis1NLViRbgLEiDnReCmVKATEj4UAf0doEc5yyHr+GlVNMmDkqkyIKg== X-Received: by 10.55.184.68 with SMTP id i65mr10910313qkf.5.1478577191625; Mon, 07 Nov 2016 19:53:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 7 Nov 2016 19:53:11 -0800 (PST) In-Reply-To: References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> From: Martin Thomson Date: Tue, 8 Nov 2016 14:53:11 +1100 Message-ID: To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Matt Caswell , "tls@ietf.org" Subject: Re: [TLS] (strict) decoding of legacy_record_version? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 03:53:14 -0000 On 8 November 2016 at 14:01, Brian Smith wrote: > Since this field isn't included in the additional_data of the AEAD in TLS > 1.3 any more, it isn't authenticated. That means an active MitM can use this > to transport up to 2 bytes of information hop-to-hop if the receiver doesn't > check it. That seems like a good reason to check it, and also to check > TLSCiphertext.opaque_type is application_data. Assuming this is the reason, > the reasoning should be explicitly called out because it is non-obvious. I don't think that's the primary reason. A MitM could use TCP headers to carry other bits if they wanted. The main reason I can think of is ecosystem health. If you permit junk, then you get junk. Then you can't use the field any more because it contains junk. From nobody Mon Nov 7 22:07:56 2016 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 3AE46129849 for ; Mon, 7 Nov 2016 22:07:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 FY14FM2J1qPx for ; Mon, 7 Nov 2016 22:07:53 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id E763C1299B9 for ; Mon, 7 Nov 2016 22:07:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 3506B12D6D; Tue, 8 Nov 2016 08:07:51 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id 3V1cNWSHgrtw; Tue, 8 Nov 2016 08:07:50 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id DA17321C; Tue, 8 Nov 2016 08:07:50 +0200 (EET) Date: Tue, 8 Nov 2016 08:07:47 +0200 From: Ilari Liusvaara To: Daniel Migault Message-ID: <20161108060747.GA8585@LK-Perkele-V2.elisa-laajakaista.fi> References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> <20161018163104.GA2405@LK-Perkele-V2.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 06:07:55 -0000 On Mon, Nov 07, 2016 at 10:16:13PM -0500, Daniel Migault wrote: > Hi, > > The current draft is only considering TLS1.2. TLS1.3 is only mentioned for > advocating AEAD. > > Do you think we should add text that details how to proceed with TLS1.3 ? > If so what do you think of the following text ? That is, I think the dependency on TLS 1.3 should be downgraded to informative (unless that has already been done). > > Yours, > Daniel > > The assigned code points are only expected to be used for TLS1.2. > TLS1.3 does not follow the same name convention. Instead TLS1.3 > cipher suites are designated according to the AEAD suite as well as > the hash function used. The current combination of AEAD algorithms > and Hash fucntion are already defined in TLS.1.3 so there is no need > to add additional cipher suites for TLS1.3. Seems reasonable. > Instead, in order to used the following ECDHE_PSK authentication > method. TLS1.3 uses a combination of the "key_share" and > "psk_key_exchange_modes" extentions. "psk_key_exchange_modes" > extension sets its mode to psk_dhe_ke. The "key_share" extention > contains a KeyShareEntry structure that carries the ECDHE parameters. > I think 'used the following' -> 'use the' and first period should be comma. -Ilari From nobody Tue Nov 8 00:24:44 2016 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 D43E9129576 for ; Tue, 8 Nov 2016 00:24:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.419 X-Spam-Level: X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 En_dUPBGJk5a for ; Tue, 8 Nov 2016 00:24:40 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8944129586 for ; Tue, 8 Nov 2016 00:24:39 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 489BDC04B943; Tue, 8 Nov 2016 08:24:39 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.171]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA88OatI005081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Nov 2016 03:24:37 -0500 Message-ID: <1478593476.2532.29.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Daniel Migault , John Mattsson Date: Tue, 08 Nov 2016 09:24:36 +0100 In-Reply-To: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Tue, 08 Nov 2016 08:24:39 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 08:24:43 -0000 On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote: > Hi,  > > Please find the text I propose. Let me know if you have any comment > regarding the proposed text. Unless I receive comment on it, the text > will be publish as soon as draft submission is possible. > > Yours,  > Daniel > >    The cipher suites defined in this document are based on the AES- > GCM >    and AES-CCM Authenticated Encryption with Associated Data (AEAD) >    algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, > and >    AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and >    AEAD_AES_256_CCM_8 defined in [RFC6655]. > >    For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF) >    with SHA-256 as the hash function SHALL be used and Clients and >    Servers MUST NOT negotiate curves of less than 255 bits. Sorry for not getting back into previous discussions. My comment as before would be to remove the text "Clients and Servers MUST NOT negotiate curves of less than 255 bits." I find that unrelated to the purpose of the text which is define code points for certain ciphersuites, and no other code points for TLS set such restrictions (DH bits, or curves). Alternatively if with this document you want to create a profile of TLS (e.g, like SuiteB rfc does), which sets options which are more than just ciphersuites then just be clear about it. That is, say this document creates a profile of TLS named XXX which if used, the clients and servers which conform to it must negotiate the ciphersuites defined above and must not negotiate curves of less than 255 bits.  regards, Nikos From nobody Tue Nov 8 00:50:57 2016 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 019C3129C4C for ; Tue, 8 Nov 2016 00:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KkxEkJunv8sE for ; Tue, 8 Nov 2016 00:50:52 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 C3A55129C4B for ; Tue, 8 Nov 2016 00:50:52 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id q124so191489521itd.1 for ; Tue, 08 Nov 2016 00:50:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=vUWHaKfR61LLcaftO1r68zmGuFEb7M52MzUngaAtSpo=; b=p5eYjlaA1y6QS205dElbKnKQktEQ4aYwO3izTOseadmJOueDvdXiLbhUbNnMqKzK+9 Z4gbddNv0HQTMj3VK/S8KBCarqQpbAs4m6JKZA3EiZhTO1mfhUaZZmSrNSTDdt3Hyamf cvp9M7MWXnWSr73Tn/aEyOVDTgq3fF2evyQApgZBBsC99UhCYkJxtPFmWMea5LDLN9Z/ Gc72PrxqadVdXpyknbb/NjjBeeJ328ox7L/0KcneNwLcWNn/HdTqI6qv3QpiHrhyWIYf LQ+4kMR1sS66CqtOmURJyFSDJ0IYemV+xTBDdEvWcIqWVyKzjLltuni4a+G1LWMlW6Jb eufg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=vUWHaKfR61LLcaftO1r68zmGuFEb7M52MzUngaAtSpo=; b=dPDbECj+D9ImLnh1QLAHRt5aoe7+Z7ByRdvM2uNGVkX1+WYO22rSXos8UWRDvnB2xH C5DY7Y+ZwdBYM81kdpGzeluIFWbbKcmn1imLLJuwbP2YVQ6a3Y/i7ECAPKDGbj4Fm+r7 SSf5FEPBBUja2hMbefzMbtSkdS+yBxCVw1pNQO+n83tzVMAiFS6wLPOAZu5856baMyh3 Tw3wJgJ484Jtjnmete/7UXgSFaNE37aqfllR3BDaJ5fqf7DZ8dhVK5hFB1cv8GUBxX26 XiuGguFCwAYbj8dNYy45/8hEPgReWn//c0UMQVBEOpath2cPVtQldhR0MXtUA6hB8VLO ZrQw== X-Gm-Message-State: ABUngvfmDk02bd+ICM7Z01A8otyA9EH6NvLngzlCPwCodcuDcN/MORIndd/unUAwRzcO95v3Weq7eOqBUQil4A== X-Received: by 10.36.129.212 with SMTP id q203mr9386175itd.120.1478595051625; Tue, 08 Nov 2016 00:50:51 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Tue, 8 Nov 2016 00:50:51 -0800 (PST) In-Reply-To: <1478593476.2532.29.camel@redhat.com> References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> <1478593476.2532.29.camel@redhat.com> From: Daniel Migault Date: Tue, 8 Nov 2016 03:50:51 -0500 X-Google-Sender-Auth: hdfEgyCGXgxpYsWh5CiaeadCqlg Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=94eb2c08b238d1a3320540c63cf9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 08:50:55 -0000 --94eb2c08b238d1a3320540c63cf9 Content-Type: text/plain; charset=UTF-8 Hi Martin, Niko, Thanks for the comment. Regarding Martin comment, I agree the text should not comment the SHAX as these are defined by the cipher suites. What is not clear to me is how the reference to DH should be handled. I also did not feel that the provided text provides different recommendations for the AES-128 / AES-256. This is the text I would propose then. Please let me know if it catches your comments and feel free to comment on it. Regarding Niko, my understanding is that the WG preferred not to have the definition of profiles in this document. I am not sure you wanted the text to be removed as MUST NOT was to normative or if you would like no recommendation at all. The reason I would rather advocate for recommendation is that ECDHE does not specify an algorithm with a specific security. As a result, I would rather provide some guide lines to avoid weak authentication being used with high long AES keys. Yours, Daniel -- Text -- When choosing AES-128 cipher suites, servers SHOULD select a key exchange that is at least 224 bits for cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE)[RFC4492]. When choosing AES-256 cipher suites, servers SHOULD select a key exchange that is at least 384 bits for cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE)[RFC4492]. TLS enable curve negotiation but not for code point. This makes restrictions on code points hard to implement. As a result Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a connection error of type insufficient_security(71) for TLS 1.2 and TLS 1.3. On Tue, Nov 8, 2016 at 3:24 AM, Nikos Mavrogiannopoulos wrote: > On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote: > > Hi, > > > > Please find the text I propose. Let me know if you have any comment > > regarding the proposed text. Unless I receive comment on it, the text > > will be publish as soon as draft submission is possible. > > > > Yours, > > Daniel > > > > The cipher suites defined in this document are based on the AES- > > GCM > > and AES-CCM Authenticated Encryption with Associated Data (AEAD) > > algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_128_CCM, > > and > > AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8 and > > AEAD_AES_256_CCM_8 defined in [RFC6655]. > > > > For the AES-128 cipher suites, the TLS Pseudorandom Function (PRF) > > with SHA-256 as the hash function SHALL be used and Clients and > > Servers MUST NOT negotiate curves of less than 255 bits. > > Sorry for not getting back into previous discussions. My comment as > before would be to remove the text "Clients and Servers MUST NOT > negotiate curves of less than 255 bits." > > I find that unrelated to the purpose of the text which is define code > points for certain ciphersuites, and no other code points for TLS set > such restrictions (DH bits, or curves). Alternatively if with this > document you want to create a profile of TLS (e.g, like SuiteB rfc > does), which sets options which are more than just ciphersuites then > just be clear about it. > > That is, say this document creates a profile of TLS named XXX which if > used, the clients and servers which conform to it must negotiate the > ciphersuites defined above and must not negotiate curves of less than > 255 bits. > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c08b238d1a3320540c63cf9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin, Niko,

Thanks for the comment. Rega= rding Martin comment, I agree the text should not comment the SHAX as these= are defined by the cipher suites. What is not clear to me is how the refer= ence to DH should be handled. I also did not feel that the provided text pr= ovides different recommendations for the AES-128 / AES-256.=C2=A0=C2=A0
This is the text I would propose then. Please let me know if it catche= s your comments and feel free to comment on it.

Regardin= g Niko, my understanding is that the WG preferred not to have the definitio= n of profiles in this document. I am not sure you wanted the text to be rem= oved as MUST NOT was to normative or if you would like no recommendation at= all. The reason I would rather advocate for recommendation is that ECDHE d= oes not specify an algorithm with a specific security. As a result, I would= rather provide some guide lines to avoid weak authentication being used wi= th high long AES keys.=C2=A0

Yours,
Daniel
-- Text --
When choosing AES-128 cipher suites, servers SHOULD select a key ex= change that is at least 224 bits for cipher suites that use ephemeral ellip= tic curve Diffie-Hellman (ECDHE)[RFC4492].

When choosing AES-256 cip= her suites, servers SHOULD select a key exchange that is at least 384 bits = for cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE)[= RFC4492].

TLS enable curve negotiation but not for code point.=C2=A0= This makes restrictions on code points hard to implement.=C2=A0 As a resul= t Endpoints MAY treat negotiation of key sizes smaller than the lower limit= s as a connection error of type insufficient_security(71) for TLS 1.2 and T= LS 1.3.

On Tue, Nov 8, 2016 at 3:24 AM, Nikos Mavrogiannopoulos <nmav@redhat.c= om> wrote:
On Mon, 2016-11-07 at 22:09 -0500, Daniel Migault wrote:
> Hi,=C2=A0
>
> Please find the text I propose. Let me know if you have any comment > regarding the proposed text. Unless I receive comment on it, the text<= br> > will be publish as soon as draft submission is possible.
>
> Yours,=C2=A0
> Daniel
>
> =C2=A0=C2=A0 The cipher suites defined in this document are based on t= he AES-
> GCM
> =C2=A0=C2=A0 and AES-CCM Authenticated Encryption with Associated Data= (AEAD)
> =C2=A0=C2=A0 algorithms AEAD_AES_128_GCM, AEAD_AES_256_GCM, AEAD_AES_1= 28_CCM,
> and
> =C2=A0=C2=A0 AEAD_AES_256_CCM defined in [RFC5116], AEAD_AES_128_CCM_8= and
> =C2=A0=C2=A0 AEAD_AES_256_CCM_8 defined in [RFC6655].
>
> =C2=A0=C2=A0 For the AES-128 cipher suites, the TLS Pseudorandom Funct= ion (PRF)
> =C2=A0=C2=A0 with SHA-256 as the hash function SHALL be used and Clien= ts and
> =C2=A0=C2=A0 Servers MUST NOT negotiate curves of less than 255 bits.<= br>
Sorry for not getting back into previous discussions. My comment as<= br> before would be to remove the text "Clients and Servers MUST NOT
negotiate curves of less than 255 bits."

I find that unrelated to the purpose of the text which is define cod= e
points for certain ciphersuites, and no other code points for TLS set
such restrictions (DH bits, or curves). Alternatively if with this
document you want to create a profile of TLS (e.g, like SuiteB rfc
does), which sets options which are more than just ciphersuites then
just be clear about it.

That is, say this document creates a profile of TLS named XXX which if
used, the clients and servers which conform to it must negotiate the
ciphersuites defined above and must not negotiate curves of less than
255 bits.=C2=A0

regards,
Nikos

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c08b238d1a3320540c63cf9-- From nobody Tue Nov 8 01:49:12 2016 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 D64321295DA for ; Tue, 8 Nov 2016 01:49:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.419 X-Spam-Level: X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 MkuxBOIFDpJG for ; Tue, 8 Nov 2016 01:49:10 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2793F1295D7 for ; Tue, 8 Nov 2016 01:49:10 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DAC478F275; Tue, 8 Nov 2016 09:49:09 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.171]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uA89n7JG023446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 8 Nov 2016 04:49:09 -0500 Message-ID: <1478598547.2532.57.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Daniel Migault Date: Tue, 08 Nov 2016 10:49:07 +0100 In-Reply-To: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> <1478593476.2532.29.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 08 Nov 2016 09:49:09 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 09:49:11 -0000 On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote: > Regarding Niko, my understanding is that the WG preferred not to have > the definition of profiles in this document. I am not sure you wanted > the text to be removed as MUST NOT was to normative or if you would > like no recommendation at all. The reason I would rather advocate for > recommendation is that ECDHE does not specify an algorithm with a > specific security. As a result, I would rather provide some guide > lines to avoid weak authentication being used with high long AES > keys.   That's a valid concern, but TLS doesn't have the notion of a security level, and I am not sure that you can easily introduce it with a ciphersuite point assignment rfc. With TLS you can easily use AES-256 with DHE-RSA with DH parameters of 4096-bits, signed with an RSA certificate of 32-bits. One can use your draft with a 8-bit PSK, and still be insecure despite the fact that you force a 256-bit curve or better. When trying to ensure a consistent level you may likely need to adjust the finished message size as well. Nevertheless, I think to cover your goal, a security considerations addition that makes apparent that in addition to the ciphersuite parameters, the TLS protocol finished message size, the elliptic curves used, and the size of the selected key define the security level of the session. regards, Nikos From nobody Tue Nov 8 02:08:12 2016 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 7244D129625 for ; Tue, 8 Nov 2016 02:08:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 222RKjnawOLx for ; Tue, 8 Nov 2016 02:08:09 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 C33CF129495 for ; Tue, 8 Nov 2016 02:08:09 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id u205so196261211itc.0 for ; Tue, 08 Nov 2016 02:08:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=0+WWSTOlAhS31MoP0NbK5cgAKGQEBPyeAsIPYPysYsw=; b=TIaGKDzMfDRrcnp460V9hqagHVL55ELhY4Jas37m54bzJbkzElR1SZM6OhLlVniB9W DlmOLTOuLLk8GTWLZ7kMZJhDpQxjyzuf1Qj31+mZs4EUzUHrcWLBeWT/oeo4UBgLExwC tIYtQf7o8t/isAVFO3YtHh5S8niM5Wxl+b9nRNf0ShI4STm3mwtnyvO3+lwywBpoHrCr oNMCizo4RX7rAUtGHF/2mFcCln4O2aCEMplmKmvkuyBE5h8AO4J7Hc8ArCVKlVEYZT9Z Px83x8jYiaV+l8j1SNW2k+/u0Kkiu3Gaf+q8OR4Wci2FzTmuJM6D6C6DzF3QRrPBYfkf UGIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=0+WWSTOlAhS31MoP0NbK5cgAKGQEBPyeAsIPYPysYsw=; b=Sa0RGeqvaqIuuv62mABqm17a3aGJta0NSoN8h7s/afGks7zTtKINYoux0ThBTNZDin x8/K/VIrOZPXllQS4vFPfZ3kdg8sStVT4ZyjGYtT08cPG4JdYkVV2qQILLp0HRgTxkHu 1p5AxH8DYyHkQ6cbKPQB+2NndWWsJT1PKr6vYUqFIzeIrSlZ2f0Ej6o0SdQ2HiJGGB4X T442+WmrD5QIivUzTXnN3O+COouCCUMNCLJboao1kpKFqHPfYulZZhsgqwvGpJsZmd/c eP+YmCuO2AZ72pMgC1zLxweBpqfneXqltGD75MGuaTnJPr2YLGscsFLfhHowK48QMbAs W5Iw== X-Gm-Message-State: ABUngvcI8ddcAzu3MhervMalKEyWzU+/toDwwsa2ThAPRdAbdgpcoP2jfBEuoSpGe2ZaIKY/n0zGLiK+nlxJAQ== X-Received: by 10.36.36.3 with SMTP id f3mr8433904ita.101.1478599688975; Tue, 08 Nov 2016 02:08:08 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.188.4 with HTTP; Tue, 8 Nov 2016 02:08:08 -0800 (PST) In-Reply-To: <1478598547.2532.57.camel@redhat.com> References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> <1478593476.2532.29.camel@redhat.com> <1478598547.2532.57.camel@redhat.com> From: Daniel Migault Date: Tue, 8 Nov 2016 05:08:08 -0500 X-Google-Sender-Auth: Adtwqn4ktfQade-sopyWDbViNPE Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a1146f0b239f9b80540c75159 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 10:08:11 -0000 --001a1146f0b239f9b80540c75159 Content-Type: text/plain; charset=UTF-8 If I understand correctly, you recommend something that is of the flavor in the security recommendation section: TLS enable curve negotiation but not for code point. This makes restrictions on code points hard to implement. As a result Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a connection error of type insufficient_security(71) for TLS 1.2 and TLS 1.3. If that is correct I will propose some better text explaining why we can hardly provide some better text, including the one provided by HTTP2. Yours, Daniel On Tue, Nov 8, 2016 at 4:49 AM, Nikos Mavrogiannopoulos wrote: > On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote: > > > Regarding Niko, my understanding is that the WG preferred not to have > > the definition of profiles in this document. I am not sure you wanted > > the text to be removed as MUST NOT was to normative or if you would > > like no recommendation at all. The reason I would rather advocate for > > recommendation is that ECDHE does not specify an algorithm with a > > specific security. As a result, I would rather provide some guide > > lines to avoid weak authentication being used with high long AES > > keys. > > That's a valid concern, but TLS doesn't have the notion of a security > level, and I am not sure that you can easily introduce it with a > ciphersuite point assignment rfc. With TLS you can easily use AES-256 > with DHE-RSA with DH parameters of 4096-bits, signed with an RSA > certificate of 32-bits. One can use your draft with a 8-bit PSK, and > still be insecure despite the fact that you force a 256-bit curve or > better. When trying to ensure a consistent level you may likely need to > adjust the finished message size as well. > > Nevertheless, I think to cover your goal, a security considerations > addition that makes apparent that in addition to the ciphersuite > parameters, the TLS protocol finished message size, the elliptic curves > used, and the size of the selected key define the security level of the > session. > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1146f0b239f9b80540c75159 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

If I understan= d correctly, you recommend something that is of the flavor in the security = recommendation section:

TLS enable curve negotiation but not for cod= e point. This makes restrictions on code points hard to implement.=C2=A0 As= a result=20 Endpoints MAY treat negotiation of key sizes smaller than the lower=20 limits as a connection error of type insufficient_security(71) for TLS=20 1.2 and TLS 1.3.

If that is co= rrect I will propose some better text explaining why we can hardly provide = some better text, including the one provided by HTTP2.

= Yours,
D= aniel


On Tue, Nov 8, 2016 at 4:49 AM, Nikos Mavrogiannopoulos <nmav@redh= at.com> wrote:
On Tue, 2016-11-08 at 03:50 -0500, Daniel Migault wrote:

> Regarding Niko, my understanding is that the WG preferred not to have<= br> > the definition of profiles in this document. I am not sure you wanted<= br> > the text to be removed as MUST NOT was to normative or if you would > like no recommendation at all. The reason I would rather advocate for<= br> > recommendation is that ECDHE does not specify an algorithm with a
> specific security. As a result, I would rather provide some guide
> lines to avoid weak authentication being used with high long AES
> keys.=C2=A0=C2=A0

That's a valid concern, but TLS doesn't have the notion of a= security
level, and I am not sure that you can easily introduce it with a
ciphersuite point assignment rfc. With TLS you can easily use AES-256
with DHE-RSA with DH parameters of 4096-bits, signed with an RSA
certificate of 32-bits. One can use your draft with a 8-bit PSK, and
still be insecure despite the fact that you force a 256-bit curve or
better. When trying to ensure a consistent level you may likely need to
adjust the finished message size as well.

Nevertheless, I think to cover your goal, a security considerations
addition that makes apparent that in addition to the ciphersuite
parameters, the TLS protocol finished message size, the elliptic curves
used, and the size of the selected key define the security level of the
session.

regards,
Nikos

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1146f0b239f9b80540c75159-- From nobody Tue Nov 8 07:26:06 2016 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 DCBDF1295F9 for ; Tue, 8 Nov 2016 07:26:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 SNzs5AYrmlpj for ; Tue, 8 Nov 2016 07:26:02 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC8761296F8 for ; Tue, 8 Nov 2016 07:26:01 -0800 (PST) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3tCtS76yZlz25Wh; Tue, 8 Nov 2016 16:25:59 +0100 (CET) X-purgate-ID: 152705::1478618760-0000521C-05015A4A/0/0 X-purgate-size: 3553 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3tCtS61vBDzkmmm; Tue, 8 Nov 2016 16:25:58 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 370F91A57E; Tue, 8 Nov 2016 16:25:58 +0100 (CET) In-Reply-To: <735A85B6-DDCF-48FC-8EF8-F31D44762F74@gmail.com> To: Yoav Nir Date: Tue, 8 Nov 2016 16:25:58 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161108152558.370F91A57E@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Tue, 08 Nov 2016 15:26:05 -0000 Yoav Nir wrote: > >> On 3 Nov 2016, at 20:20, Martin Rex wrote: >> >>> With visible content type, you can tell these two flows apart. >> >> (a) so what? for those interested, one can tell such flows appart >> pretty reliably by traffic analysis. So there is exactly ZERO >> protection against bad guys, while breaking the good guys. > > There is if you pad the records to the size of application records. There is no such padding by default. And the TLS handshake is half-duplex, and for any interested third party, who performs the handshake with the server himself for comparison, the PDUs are still pretty much predictable heuristically (by their ordering), even when they're padded. So besides being completely pointless, can you describe any realistic problem that is worth breaking middleware at the endpoints so badly? > > > (b) but TLSv1.2 remains unchanged, and this flow does not seem to > > exist in TLSv1.3, since renegotiation no longer exists in TLSv1.3. > > Re-negoatiation doesn?t, but post-handshake client authentication does: > https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.5.2 > > > -- so why would we need a backwards-incompatible change in a > > protocol that protects something that no longer exists, > > but which severely breaks existing middleware, making it > > impossible to drop-in replace a TLSv1.2 implementation with > > a TLSv1.3 implementation that has this backwards-incompatibility. > > Can you elaborate on that middleware? As previously mentioned, it is middleware that facilitates using a TLS-protected communication channel for application callers. It offers several different kinds of reading strategies to the caller, which the caller is free to choose from. One reading mode is "streaming", where as many app-data TLS records are read (non-blocking) and decrypted, as fit into the application-supplied buffer. This facilitates communication with servers that fragment app data into pathologically small pieces (e.g. Google). Non-Appdata records (such as a final Close-Notify or a renegotiation request) are left in the network buffers, and will only be fully read&processed after all AppData preceding it have been properly returned to the application. In a similar fashion, the reverse proxy part (often in the DMZ), can check whether a browser prematurely aborts a communication and closes the network connection, by checking for readable events on the network socket and peeking whether it is a hard connection closure (TCP RESET, such as MSIE), or a CloseNotify Alert (Firefox,Chrome), without reading&decoding any application data. For large-scale Servers, non-blocking network operations are much more efficient than blocking network operations, the general wait point of the application is a select/poll call which waits on sockets, and it is up to the application to decide whether to "select for read" when it is ready to receive application data on a communication channel. With appdata records clearly distinguishable at the outer TLS record layer, the event-based architecture of the application did not need any changes when switching from cleartext communication to TLS-encrypted communication, all app-data socket-readable events remained visible with SSLv3->TLSv1.2, because TLS appdata records can be clearly distinguished from Handshake, CCS and Alert. -Martin From nobody Tue Nov 8 10:18:47 2016 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 6E1B21299C7 for ; Tue, 8 Nov 2016 10:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 sBB-W-TttYaU for ; Tue, 8 Nov 2016 10:18:45 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id AA9B51294B5 for ; Tue, 8 Nov 2016 10:18:20 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B328B43340D; Tue, 8 Nov 2016 18:18:19 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 753884DC05; Tue, 8 Nov 2016 18:18:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478629099; bh=4c2nFFsdq4aKxQvevpzzC2mt1KTm7ohGAZGlbkt8PL4=; l=723; h=From:To:CC:Date:References:In-Reply-To:From; b=IdypUT2EaYMnjrv3y4o+yaxDQE7TyD2qz9PUk8F132xKW/a20dgSWGBfQ5QYWUtIL T5hRNXo+pmk5ydp1Ta5Ut5c5QSUJ1ah74mxMZbUBjFegR0nT+ZyMQSopXszfZOcA57 FlVDkl5UJ/3FF9mo+AIpVwGtOaFrAgK/b0CdtmyY= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 719661FCBE; Tue, 8 Nov 2016 18:18:19 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb3.msg.corp.akamai.com (172.27.123.103) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 8 Nov 2016 13:18:18 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 8 Nov 2016 13:18:18 -0500 From: "Salz, Rich" To: "mrex@sap.com" , Yoav Nir Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 Thread-Index: AQHSL/2+7HM9ClSQ40Wwf3PQxwdBMaC+S8KAgAAG0ACAACSwgIABS5EAgAfeKgCAADJLgIAADcgAgAAE9wCAB7aeAP//2qmA Date: Tue, 8 Nov 2016 18:18:18 +0000 Message-ID: <61800c8dd50f4a1a911f8f2c96b65dda@usma1ex-dag1mb1.msg.corp.akamai.com> References: <735A85B6-DDCF-48FC-8EF8-F31D44762F74@gmail.com> <20161108152558.370F91A57E@ld9781.wdf.sap.corp> In-Reply-To: <20161108152558.370F91A57E@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.118] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 18:18:46 -0000 > the PDUs are still pretty much predictable > heuristically (by their ordering), even when they're padded. ... =20 > So besides being completely pointless, can you describe any realistic pro= blem > that is worth breaking middleware at the endpoints so badly? I found the language difference interesting. We could conduct an interesti= ng thought experiment by reversing the emphasis on each of the above fragme= nts. But I won't. Instead, I'll point out that this is in-charter, in-scope, and WG consensus= has generally been to "encrypt all the bits" as much as feasible. Some applications in some corners of some enterprises, might lose out. Just like those who depending on static RSA, right? From nobody Tue Nov 8 10:59:54 2016 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 CFCFE129DAA for ; Tue, 8 Nov 2016 10:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=briansmith-org.20150623.gappssmtp.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 vy3xZwvK3lj7 for ; Tue, 8 Nov 2016 10:59:50 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 B6205129DA8 for ; Tue, 8 Nov 2016 10:59:16 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id u205so226610609itc.0 for ; Tue, 08 Nov 2016 10:59:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=briansmith-org.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=IKS5tbJ+vVmsAOYxkd7OY56rAaV+tYRCH2Ig9XnN90c=; b=L46aMHbSDSkXauYAnwmShyRM+7GyboXoJmuG+1zPb9w46tsROehswse4lapSr8caTQ TCOU3G7xbdxvZygMQB+Vw6fgmFYWyP2kR3fyyP7Pd+XRc6hnbwbGkEYptsg/p/KleaNo +tJESdAkF+zeG4ZCSqO19c9gpLr9XSR0PHpza7Cxs50RsbSEf+dgTEV9Dx6JyjjRdTYp c0n3FNda0Qmzr3PX+0nRVSNl1t1pwh1jWhfoOSYKb+cfWsEU3I62OEkqrpeb6gFbwAz6 xuv6xozS4+hw9jDMIxSI95j96wWMPZ8SsZUcZlCdTcq/JL3xWcxXMPvS1MEiQyQotNd2 P6Jg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IKS5tbJ+vVmsAOYxkd7OY56rAaV+tYRCH2Ig9XnN90c=; b=gau5NNBnQnwcgTyXPNJNb7Y8SQM0QqM5Qv30OR8LAJbBTbZJbaEaWWWBE7RyWBVMgp t6qLdCj30zzCCO7foYJCk/Hgz35lbG8o+GSd0Ak/NjwYKbyrLx/L/h+lS5xYcZ8UtkNT 6E0kItHKZMALSJgOG0wBwyzD9xuRmaVk9sCejDlVhqBxjpWzau4Z8j+HnPHyKwjMIGMn nNC2TL+QS+2+gi7hJuA8NJKJnfuvY94W9gr/J6g6ATEiyqTN916992n6HzyU97v2rxUV yK5yXyiNDHj1Tpd4t4P2SoUr3+KNm0GlmkCCwcF+0d3xLTxq8uQavIT11uvBc7m6hav6 BIlQ== X-Gm-Message-State: ABUngvcFXvUOZy9iqiWzTYYXIBGsT1xoYbl9zvXazCaUWV+02icsvuKy4tzHi5aot4aRsS8/Hf0zdtdElqqtmw== X-Received: by 10.107.1.138 with SMTP id 132mr13988797iob.72.1478631555955; Tue, 08 Nov 2016 10:59:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.85.83 with HTTP; Tue, 8 Nov 2016 10:59:15 -0800 (PST) In-Reply-To: References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> From: Brian Smith Date: Tue, 8 Nov 2016 08:59:15 -1000 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113965aea5ab810540cebc23 Archived-At: Cc: Matt Caswell , "tls@ietf.org" Subject: Re: [TLS] (strict) decoding of legacy_record_version? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 18:59:53 -0000 --001a113965aea5ab810540cebc23 Content-Type: text/plain; charset=UTF-8 Martin Thomson wrote: > On 8 November 2016 at 14:01, Brian Smith wrote: > > Since this field isn't included in the additional_data of the AEAD in TLS > > 1.3 any more, it isn't authenticated. That means an active MitM can use > this > > to transport up to 2 bytes of information hop-to-hop if the receiver > doesn't > > check it. That seems like a good reason to check it, and also to check > > TLSCiphertext.opaque_type is application_data. Assuming this is the > reason, > > the reasoning should be explicitly called out because it is non-obvious. > > I don't think that's the primary reason. A MitM could use TCP headers > to carry other bits if they wanted. > Smuggling at the application layer would be more reliable for them, though. I'd say the goal of the check isn't to prevent all possible smuggling; rather it's part of a solution to it. Anyway, this is the only convincing rationale I see for requiring ("MUST") vs allowing ("MAY") the checking. > The main reason I can think of is ecosystem health. If you permit > junk, then you get junk. Then you can't use the field any more > because it contains junk. > This isn't a pervasively shared goal, though. It's good to let the browsers police things if they want, but I think a lot of implementations would prefer to avoid doing work that isn't necessary for interop or security. Cheers, Brian -- https://briansmith.org/ --001a113965aea5ab810540cebc23 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com> wrote:
On 8 November 2016 at 14:01, Bri= an Smith <brian@briansmith.org> wrote:
> Since this field isn't included in the additional_data of the AEAD= in TLS
> 1.3 any more, it isn't authenticated. That means an active MitM ca= n use this
> to transport up to 2 bytes of information hop-to-hop if the receiver d= oesn't
> check it. That seems like a good reason to check it, and also to check=
> TLSCiphertext.opaque_type is application_data. Assuming this is the re= ason,
> the reasoning should be explicitly called out because it is non-obviou= s.

I don't think that's the primary reason.=C2=A0 A MitM could = use TCP headers
to carry other bits if they wanted.

Smu= ggling at the application layer would be more reliable for them, though. I&= #39;d say the goal of the check isn't to prevent all possible smuggling= ; rather it's part of a solution to it. Anyway, this is the only convin= cing rationale I see for requiring ("MUST") vs allowing ("MA= Y") the checking.

=C2=A0
The main reason I can think of is ecosystem health.=C2=A0 I= f you permit
junk, then you get junk.=C2=A0 Then you can't use the field any more because it contains junk.

This isn't a pe= rvasively shared goal, though. It's good to let the browsers police thi= ngs if they want, but I think a lot of implementations would prefer to avoi= d doing work that isn't necessary for interop or security.

=
Brian
--
--001a113965aea5ab810540cebc23-- From roel.peeters@esat.kuleuven.be Tue Nov 8 06:55:46 2016 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 6607F129CD5 for ; Tue, 8 Nov 2016 06:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 BTIHrGpIrDMF for ; Tue, 8 Nov 2016 06:55:44 -0800 (PST) Received: from cavuit02.kulnet.kuleuven.be (rhcavuit02.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:130]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 535B7129588 for ; Tue, 8 Nov 2016 06:55:43 -0800 (PST) X-KULeuven-Envelope-From: roel.peeters@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 09A7E128089.A1DC0 X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-1.cc.kuleuven.be (icts-p-smtps-1e.kulnet.kuleuven.be [134.58.240.33]) by cavuit02.kulnet.kuleuven.be (Postfix) with ESMTP id 09A7E128089 for ; Tue, 8 Nov 2016 15:55:36 +0100 (CET) Received: from hydrogen.esat.kuleuven.be (hydrogen.esat.kuleuven.be [134.58.56.153]) by icts-p-smtps-1.cc.kuleuven.be (Postfix) with ESMTP id 05E65403B for ; Tue, 8 Nov 2016 15:55:36 +0100 (CET) Received: from guillotine.esat.kuleuven.be (guillotine.esat.kuleuven.be [10.33.137.85]) by hydrogen.esat.kuleuven.be (Postfix) with ESMTP id 10E416002E; Tue, 8 Nov 2016 15:55:36 +0100 (CET) To: tls@ietf.org X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Roel Peeters Organization: KU Leuven - ESAT - SCD/COSIC Message-ID: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> Date: Tue, 8 Nov 2016 15:55:36 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: X-Mailman-Approved-At: Tue, 08 Nov 2016 12:51:36 -0800 Cc: Jens Hermans Subject: [TLS] COSIC's look on TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 15:22:02 -0000 Dear all, just to let you know that we have written a blog post on the current TLS 1.3 draft, with our remarks that might be of use in your upcoming meeting. https://securewww.esat.kuleuven.be/cosic/?p=6624 Best regards, Roel Peeters and Jens Hermans PS: we are also wondering whether or not the Hello Retry Request will be included or omitted in the standard. Leaving it out will make TLS 1.3 vulnerable again to downgrade attacks ... From nobody Tue Nov 8 12:58:59 2016 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 2406F129693 for ; Tue, 8 Nov 2016 12:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 13ZK1BDoRhvU for ; Tue, 8 Nov 2016 12:58:56 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 5485A129582 for ; Tue, 8 Nov 2016 12:58:56 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id l124so192567875ywb.3 for ; Tue, 08 Nov 2016 12:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3NbDKihQQBeXZHQRZuSaUCJaEWXm48wOKA7YGDUDgpk=; b=h5oFjpFBR96mPjRRmXu+D8Zjrb3RW4OBPqkgKX61RGy2RZLZXLA/OEbd7TULOlkc2Y G1MUNbNmXigxpg90k1b3bxvG5sl1KX1El1gcrWaGPAozoVnSNQo9xSTUnNH01b5kN9CG vX+ext8VauMRNXSrLcLITvejLHFoCFtBbHRjI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3NbDKihQQBeXZHQRZuSaUCJaEWXm48wOKA7YGDUDgpk=; b=ip8Jkut6nPZ8dD9YLkv633oDkcl+sJWaVL+kDKaJeUvOKFJxq4O7cAD2L9dSuIvw97 +bh93pHHRStME0hN7wpcHAU7pHYEUOc/Oi8vX7oipIQf1Y04Rtpfd7wJC38955Vsvo4Z 0gkkPEylY4CjbQg/QFpVgmJ78ZoaDwIbG/+ePQrA9n0BNwQRGL5dm7QHmPVo3Q8gBuaO 3LSzczFQRBO8NFfHKkn8+80qaW1iMCT6kH4sR2RqssSgT5aOdWGe+k65tuBFBVkgZUZ+ ikg8jXgrmNucT5Lj8eZqpIauQUC9+N+y7ovf74jnQIrOO7JHNobule/D3eAA2097vSex fYnQ== X-Gm-Message-State: ABUngvcP/L2VxxGof1a/gizVfQ1QY9hOLW9lAVZxMIR/BmFcSaGcGQDHWxBZ3W1h/XjpQQ== X-Received: by 10.157.40.58 with SMTP id m55mr7088823otb.209.1478638735576; Tue, 08 Nov 2016 12:58:55 -0800 (PST) Received: from [5.5.33.27] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id 30sm7201459otx.14.2016.11.08.12.58.53 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 08 Nov 2016 12:58:55 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> Date: Wed, 9 Nov 2016 02:28:45 +0530 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> To: Roel Peeters X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Jens Hermans , tls@ietf.org Subject: Re: [TLS] COSIC's look on TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 20:58:58 -0000 I let this message through the moderator queue despite the link to the = blog; next time please send your comments directly to the list. Note = that I wouldn=E2=80=99t necessarily expect anybody to pick up your = points for you; PRs are welcome though. spt > On Nov 08, 2016, at 20:25, Roel Peeters = wrote: >=20 > Dear all, >=20 > just to let you know that we have written a blog post on the current = TLS > 1.3 draft, with our remarks that might be of use in your upcoming = meeting. >=20 > https://securewww.esat.kuleuven.be/cosic/?p=3D6624 >=20 > Best regards, >=20 > Roel Peeters and Jens Hermans >=20 > PS: we are also wondering whether or not the Hello Retry Request will = be > included or omitted in the standard. Leaving it out will make TLS 1.3 > vulnerable again to downgrade attacks ... >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 8 13:26:08 2016 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 D6303129AB7 for ; Tue, 8 Nov 2016 13:26:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovfcAlvpPQGF for ; Tue, 8 Nov 2016 13:26:06 -0800 (PST) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 614F012948A for ; Tue, 8 Nov 2016 13:26:06 -0800 (PST) Received: by mail-qk0-x241.google.com with SMTP id n204so15816205qke.2 for ; Tue, 08 Nov 2016 13:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=mBfZEkNB3lNuYbWbssAbAK2jDPNYTZmEIH3tJZbjDK4=; b=k1XxCCJRaow2rQMaUSdAnw7TnqG61so8PT4bgIChUaD3fw0T3O/0g+Q3/fprtmhJ3b DLX2RFwP0kUIRJIGIx2kIXJpyYTqzXsXBQHS9VblhPZf1ulP3hugZGa56teV3pdG8BA4 4vC+445MgsBvtdSQPiwbQBv2qZRaIdH69ujLfs1HsrfhTnhrAd3mbKlZTe+5XWZBGzbY mTXxbb9gU6bYKaIHU3Y1hRJaB8k6gmdEQ5DliCTB9emlgOtjnkQ5IgVutItUrW437c1Z 1qKfCS8hMC6INj2vmpwREfnSy7OukP8d2B4/XjiH2vUd+FUTVuw1VU83+1wujsrSn4it jP7w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=mBfZEkNB3lNuYbWbssAbAK2jDPNYTZmEIH3tJZbjDK4=; b=chtK+UDwSP9nSgULLX8I6fkpfbEJcioGht6y2M4mKD7cRGtTS0CN6Z18qARkW5KOxx 2JwO16N1xE6pmJKR6rEN0XoTMjftsaZW4fmV7jxukBIGHyqQZQHQ4iz1FnTc0t4dK6H7 U+CjUzAyPPc5jtzX03gheety9pPpDI1I+xaIk6bTt/2I+RGcpxeu5qyy3lLGgMAZ+Ezx 7mrZfNkZtPny6j84avzbEB/8xPKt5vV8VrGY0d6OlEA5fWjbC4iPq0rl/p8DfXNd8J7+ gFU/WdjIsCS6p0aN0Iqr1Vzi0OPAPDwBnQLHuKMbwQndxtHs7TdM1OY4++BrTFtM8BZz LMHQ== X-Gm-Message-State: ABUngvcbMQTvZcgmEtj9ChGpsYaE/fpX3Fc7wtoivy8yx6rj/3vxr62y1GC+MYLng2AC6w== X-Received: by 10.55.17.206 with SMTP id 75mr14273395qkr.10.1478640365414; Tue, 08 Nov 2016 13:26:05 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-27-43.phlapa.fios.verizon.net. [71.175.27.43]) by smtp.gmail.com with ESMTPSA id t7sm13477059qtd.13.2016.11.08.13.26.04 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 08 Nov 2016 13:26:04 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Tue, 8 Nov 2016 16:26:03 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> In-Reply-To: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201611081626.03635.davemgarrett@gmail.com> Archived-At: Cc: Jens Hermans , Roel Peeters Subject: Re: [TLS] COSIC's look on TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 21:26:08 -0000 On Tuesday, November 08, 2016 09:55:36 am Roel Peeters wrote: > we are also wondering whether or not the Hello Retry Request will be > included or omitted in the standard. Leaving it out will make TLS 1.3 > vulnerable again to downgrade attacks ... Why are you wondering about this? HRR is in the specification and there has been no discussion to remove it. Dave From nobody Tue Nov 8 14:34:01 2016 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 284EF1294E4 for ; Tue, 8 Nov 2016 14:34:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 P-8COYRm6EfA for ; Tue, 8 Nov 2016 14:33:57 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id AF9BD1294BC for ; Tue, 8 Nov 2016 14:33:57 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id D3DE616402; Wed, 9 Nov 2016 00:33:55 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id LjxxY2wrKVre; Wed, 9 Nov 2016 00:33:55 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 4AE2F289; Wed, 9 Nov 2016 00:33:55 +0200 (EET) Date: Wed, 9 Nov 2016 00:33:52 +0200 From: Ilari Liusvaara To: Roel Peeters Message-ID: <20161108223352.GA9878@LK-Perkele-V2.elisa-laajakaista.fi> References: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: Jens Hermans , tls@ietf.org Subject: Re: [TLS] COSIC's look on TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 22:34:00 -0000 On Tue, Nov 08, 2016 at 03:55:36PM +0100, Roel Peeters wrote: > Dear all, > > just to let you know that we have written a blog post on the current TLS > 1.3 draft, with our remarks that might be of use in your upcoming meeting. > > https://securewww.esat.kuleuven.be/cosic/?p=6624 Some comments: - I would expect ClientHello to identify the TLS library client uses, by fingerprinting ClientHello. E.g. btls has very characteristic ClientHello (Elliptic curve 30 and signature 0x0808 are very rare). - Outside statically provisioned PSKs, the PSK identifiers are supposed to be use-once (or at most use few times tightly spaced). - Speed matters, therefore TLS 1.3 has been designed with the greatest speed -> 2 client flights and 1 server flight till data transport is fully up. Which is theoretical minimum for any protocol with key confirmation. - Checks have bad tendency of being omitted, so I personally prefer more complex key schedule that can force the properies. - The state machine complexity mostly comes from all the messages in the handshake, none really seems removable/mergeable without introducing more problems. - The obfustication is meant for one purpose only: Prventing attackers from correlating dynamic PSK connection with its parent. Note that masking is additive, so even multiple-use of the same PSK does not allow correlation of parent session. The child sessions would be correlated, but those are easily correlated by the identifiers anyway. - Yes,the correct way is to invalidate tickets on use. The reason the mechanism is done this way is to support stateful and stateless as good as possible (obviously, stateless mechanisms have inherit problems). - Regarding 0-RTT data, yes it scares me... If just for the fact that it appears to be much more difficult to analyze than just about anything else (another scary feature is post-handshake auth, given the possiblities for applications to seriously shoot themselves to the foot with it, in non-obvious ways). - Receiving the same PSK twice is only possible within the same connection: Because associated PSK master key will be different on every connection attempt, and forcing it to be the same would require breaking the PRF hash (which already causes severe issues). - Even if client reuses PSKs, unless the ClientHellos are exactly the same (including Random field, which is supposed to be 256 random bits), the keys will almost certainly be forced different (if PRF hash is strong). This also holds for 0-RTT keys. - Yeah, there have been complaints about lack of state diagram, stating that the present ladder diagram is not sufficient. -Ilari From nobody Tue Nov 8 14:43:57 2016 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 BAF771294CD for ; Tue, 8 Nov 2016 14:43:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 BjjW-yXTq9Vw for ; Tue, 8 Nov 2016 14:43:54 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 373311295E3 for ; Tue, 8 Nov 2016 14:43:54 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id i145so101227392ywg.2 for ; Tue, 08 Nov 2016 14:43:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8KXXvc3TWhIKmj6tohLCV8ASJOjyM71Y6Ev0tNCN8II=; b=NsIipIaK7NqIA0zOWA5qVwOWm0RmXYgMOyjqa/qNo7vxJAPL7aoxkOdE44bhl/0Em0 8JVTzUrVHY6smg8+cFwEnxhL8Fg1f8oDU51s5Gid17QcSbR6rQ+MqOlBsE7WnEw6FTmG R5xvRDRC8zr+QNt1CrYKgcn9KjnjKVmTseCCZoAflTc2txs3ZFJ3WWDMI9EeOkOTCtln cFCoD6yoEClBHQGpc5UrciM2h05XePACh9HsVhrh8MJjra1I22VgZYKlkhGbPh30lCii qneuSjMqemEkzAnyOvO2AknMVNQYcIfsSYwh71feRf/uKTE0abfNYV35CwoCWEQ41rak bH9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8KXXvc3TWhIKmj6tohLCV8ASJOjyM71Y6Ev0tNCN8II=; b=Fwpoy6plrqpYVKwRTn0zw9UEEjZqMEEi1uc170rROtqsvfWztJTIwdAF1nSECJMZfu h9Sm/j2QwzJB6csU5uoJgJAWLH9OfXbwyhWbQY+QjwYUH3xxGfg77/ezIxOR60Z9IGJ/ uyxSe1rL2m+rscIC6mXsxhymjS4515hiOkl/rFUfSmdhX0fIK+yqtCWK0ibhbjVPB56i wHm/yZeWmXl7EtRe5C4YfN0cNHvd6f/B7MJ/vd1/POiDHVsRuemHDm1r7FHdprmkQ4gi eRkAaLdd0OLysbI1oPzsMYkF26FTWrjkr6eURmsxkUgfF70sWfB0TIgbjELb9dRfzsHo fXlQ== X-Gm-Message-State: ABUngveD/Oaxev2RKmD4x4/tzgJGQ8KeNYcyjt//ANE1u4XJ6dshfB7qziovZlW7wZJL8w8JhyNo7AMRZgnorQ== X-Received: by 10.129.108.216 with SMTP id h207mr14086214ywc.52.1478645033540; Tue, 08 Nov 2016 14:43:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Tue, 8 Nov 2016 14:43:13 -0800 (PST) In-Reply-To: <20161108223352.GA9878@LK-Perkele-V2.elisa-laajakaista.fi> References: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> <20161108223352.GA9878@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 8 Nov 2016 14:43:13 -0800 Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114dd36ef957520540d1df2e Archived-At: Cc: Jens Hermans , "tls@ietf.org" Subject: Re: [TLS] COSIC's look on TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 22:43:56 -0000 --001a114dd36ef957520540d1df2e Content-Type: text/plain; charset=UTF-8 On Tue, Nov 8, 2016 at 2:33 PM, Ilari Liusvaara wrote: > - Yeah, there have been complaints about lack of state diagram, stating > that the present ladder diagram is not sufficient. > Yeah, I'm taking this point to heart. I've been a bit swamped with implementation matters, but I'll get working on a state machine diagram. -Ekr > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dd36ef957520540d1df2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 8, 2016 at 2:33 PM,= Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
- Yeah, there have been complaints about lack of state diagram, stating
=C2=A0 that the present ladder diagram is not sufficient.
<= div>
Yeah, I'm taking this point to heart. I've been = a bit swamped with implementation
matters, but I'll get worki= ng on a state machine diagram.

-Ekr

=



-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114dd36ef957520540d1df2e-- From nobody Tue Nov 8 16:24:31 2016 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 1893B129513 for ; Tue, 8 Nov 2016 16:24:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hcuzW1O8mMOM for ; Tue, 8 Nov 2016 16:24:29 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 7F8C5129462 for ; Tue, 8 Nov 2016 16:24:29 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id w33so117846875qtc.3 for ; Tue, 08 Nov 2016 16:24:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=V7ybMVx7S+3wVaS4m/zVPXKT7HOmxPqzc8ZT35uVf+U=; b=u403PzkSGFceLlVOqRQ3TTKzL3PzUSopGxmExNgLtL20Ha14y1ar6WIiVVezq7XqM4 qwdgdkc+CUeGrtUvPbabWhtE9KC1Wfi8Nb/kjEVnoV9OQVPrgyQ0Z/iQ4FYGK02iPRQU KV0Lgga+gRzuPYwLkIH/McwBSjMso4n+yZpweTpQyOzQ77xCxmPsrecKBLREr1E/ga0+ eOuLd3ZirouUXFpHJgi2oXWuqqHacOUPTPm9KHT7uQhMQMIeDPt6R1Sj/NsO4KRiazho 5xzUvXsXknnLYJKS3f11zwI0LK3vRThQIcmHeaxG9yeIrkpUVVbw/yEvbCSSUwm7J1lb srqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=V7ybMVx7S+3wVaS4m/zVPXKT7HOmxPqzc8ZT35uVf+U=; b=BjDS/hUI5I1lqGaIzqRMVbfWbkFIpLdsf9WWb7b0DytWQiVz99Y5fym7R5mpvKG/O5 zIFibl8PU1adgHdOqcs+ztCgSwZElqFnWYgkuliQSdlxfWvbTv6BhfXqVdUGUvFeaHji mN/2i9rC+f8VJ14VCOY3pfq/Qb3dQza2c69H4JUBuJzDOIqXIAZVDK8XfEudFmiZxoHV otO05buRCZhwKUlSfRdVRxYqHxTcRgbgv+e9Tk89ANOKD+LK+rbdUOmhujjZzBXFHSA6 TVJ5l3AQ6OEW9uMhZBeCbUv4m9vY/mJB63RYWNjdROSatetPiuj3gP0vw9I7kG1gHutu IgZg== X-Gm-Message-State: ABUngvfyQ/UC5pXJyyaTViLaLZ8090hEgp9rrrY3NLdigJRMvJlWvzbiuEhu3mPs6EisOFB4PMMlZcwvGiLSqQ== X-Received: by 10.237.53.132 with SMTP id c4mr16384943qte.85.1478651068672; Tue, 08 Nov 2016 16:24:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 8 Nov 2016 16:24:28 -0800 (PST) In-Reply-To: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> <1478593476.2532.29.camel@redhat.com> <1478598547.2532.57.camel@redhat.com> From: Martin Thomson Date: Wed, 9 Nov 2016 11:24:28 +1100 Message-ID: To: Daniel Migault Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 09 Nov 2016 00:24:31 -0000 On 8 November 2016 at 21:08, Daniel Migault wrote: > TLS enable curve negotiation but not for code point. This makes restrictions > on code points hard to implement. As a result Endpoints MAY treat > negotiation of key sizes smaller than the lower limits as a connection error > of type insufficient_security(71) for TLS 1.2 and TLS 1.3. I really had a hard time parsing this. You don't connect this to Diffie-Hellman at all, but I think that is what you are talking about. But if your point is that this is an ECDHE-specific draft, then you don't need to say anything at all. nit "TLS enables" From nobody Tue Nov 8 16:25:41 2016 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 06643129565 for ; Tue, 8 Nov 2016 16:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X4la66yVKJlx for ; Tue, 8 Nov 2016 16:25:38 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 BA36F129462 for ; Tue, 8 Nov 2016 16:25:38 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id n21so127488207qka.3 for ; Tue, 08 Nov 2016 16:25:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GHcPqXgAuDWil+FLcRL2TToHO4xgX95OrKF4Bay1ip0=; b=VktFVw9tIAOtkZXEkcyF0XnPdJ30NBcEap3Q/+esD6nN/2y+r93ueIiuf3ohVy7c6g wciZHV9SY6UZ+PIhmt55pPx5E8CcVHkymYM2doCsBJYErfefuSGS5SPuNqW7Zpc/cl2Z i42Vj/CPFJp0zakz3V4ZuCxAMnATw2LqWIgxI/Ii+UULN2JhLAJyVsLr2CCPAEppqdxk faSaeZdnNas+wg1NBAl9xa/wHhjQXL43Bm+hs2t1sQKd29akHYyvPApoz72LMgCM7EiX XZjLYmvF0fMisUmpFjg1tPXRpnaN4eA472//ZF8lmtbwPENMM+fHbX+S7i3ktt7IIXEK fjfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GHcPqXgAuDWil+FLcRL2TToHO4xgX95OrKF4Bay1ip0=; b=TtehTT8IUsw4c9c+qZoiMPvKzi/B/H+1qlNfCIiM9o4qSf8vJ+vv3DFJg3rWXVMzN6 rrk120+JD9dAQLJ+95P25XsRippFVBcQXU/w1in9STQV0toSzbpXKkRqv6I6OrPxwGa+ D8ogIY2sPQPs8+hR22vwHQII9THCXfXp+lkWxU4lgelJSSQ02s1n1OXyZZV7Ttpm+QTK SwMbLwEq9sAE4xFtwzFHej6wt0p2b0tISJ8+2bxQNd5bXIVOSqCpSKifcBliGekKx8js yHyotXrnRDuypekOhq8cmkkIgYC7V3As1gQVSzEkByO7+LO5VN8MIg/09ZhLWaXwX/je koxQ== X-Gm-Message-State: ABUngvebR9aApJ1RFoTlO4NCeKbjhnhJjt83xXdSneVt9Ry7NOF8/XRUGZUSQ7CjaZq3VZwbTImOeac0kIZa6Q== X-Received: by 10.55.184.68 with SMTP id i65mr16878113qkf.5.1478651137962; Tue, 08 Nov 2016 16:25:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 8 Nov 2016 16:25:37 -0800 (PST) In-Reply-To: References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> From: Martin Thomson Date: Wed, 9 Nov 2016 11:25:37 +1100 Message-ID: To: Brian Smith Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Matt Caswell , "tls@ietf.org" Subject: Re: [TLS] (strict) decoding of legacy_record_version? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 09 Nov 2016 00:25:40 -0000 On 9 November 2016 at 05:59, Brian Smith wrote: > This isn't a pervasively shared goal, though. It's good to let the browsers > police things if they want, but I think a lot of implementations would > prefer to avoid doing work that isn't necessary for interop or security. If you permit someone to enforce it, then that is sufficient. I don't think that we should ever force someone to enforce these sorts of things (as you say, sometimes strict enforcement isn't cheap or even desirable). From nobody Wed Nov 9 01:31:28 2016 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 1F4DA129669 for ; Wed, 9 Nov 2016 01:31:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 wKiRRPMogW6S for ; Wed, 9 Nov 2016 01:31:25 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09041295B6 for ; Wed, 9 Nov 2016 01:31:24 -0800 (PST) Received: from mail06.wdf.sap.corp (mail06.sap.corp [194.39.131.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3tDLXV6QGnz1HsZ; Wed, 9 Nov 2016 10:31:22 +0100 (CET) X-purgate-ID: 152705::1478683882-0000521C-CED8B378/0/0 X-purgate-size: 4407 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail06.wdf.sap.corp (Postfix) with ESMTP id 3tDLXV3Wq8zklgV; Wed, 9 Nov 2016 10:31:22 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6D3111A579; Wed, 9 Nov 2016 10:31:22 +0100 (CET) In-Reply-To: <61800c8dd50f4a1a911f8f2c96b65dda@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Date: Wed, 9 Nov 2016 10:31:22 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161109093122.6D3111A579@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Wed, 09 Nov 2016 09:31:27 -0000 Salz, Rich wrote: >> the PDUs are still pretty much predictable >> heuristically (by their ordering), even when they're padded. > > ... > >> So besides being completely pointless, can you describe any realistic >> problem that is worth breaking middleware at the endpoints so badly? > > I found the language difference interesting. We could conduct an > interesting thought experiment by reversing the emphasis on each > of the above fragments. But I won't. > > Instead, I'll point out that this is in-charter, in-scope, and WG consensus > has generally been to "encrypt all the bits" as much as feasible. The problem here is that this breaks (network) flow control, existing (network socket) event management, and direction-independent connection closure, and does so completely without value. When TLS records with AppData can be left in the network socket while the application layer is not ready to process & consume it, then TCP flow control works better in high load situation. The semantics defined for the TLS Closure Alert in SSLv3->TLSv1.2 is somewhat difficult for full-duplex communication, direction-independent shutdown, and confirmation of receipt: https://tools.ietf.org/html/rfc5246#section-7.2.1 7.2.1. Closure Alerts The client and the server must share knowledge that the connection is ending in order to avoid a truncation attack. Either party may initiate the exchange of closing messages. close_notify This message notifies the recipient that the sender will not send any more messages on this connection. Note that as of TLS 1.1, failure to properly close a connection no longer requires that a session not be resumed. This is a change from TLS 1.0 to conform with widespread implementation practice. Either party may initiate a close by sending a close_notify alert. Any data received after a closure alert is ignored. Unless some other fatal alert has been transmitted, each party is required to send a close_notify alert before closing the write side of the connection. The other party MUST respond with a close_notify alert of its own and close down the connection immediately, discarding any pending writes. It is not required for the initiator of the close to wait for the responding close_notify alert before closing the read side of the connection. The issue here is that the receiving TLS stack, when processing an incoming TLS CloseNotify Alert, will typically immediately respond with a TLS CloseNotifyAlert on its own, precluding the application from sending any further data in the other direction in response When hiding the TLS record ContentType, then pre-reading and coalescing (=streaming) application data records suddenly becomes a problem, because receiving and processing a hidden TLS CloseNotify Alert will cause a TLS CloseNotify Alert response (an alleged indicator for a graceful connection closure) being generated and returned even before the application has (a) seen and (b) had a chance to respond to the latest batch of application data. To prevent this from happening, and leave the decision to the application of whether to read a (potential) CloseNotify alert from the wire, I would have to go back to trickling TLS records (including those pathologically fragmented ones from Google) to the application whenever TLSv1.3 is negotiated. There is a similar (slightly smaller) issuer with the coalesced TLS handshake/alert/css record processing during the TLS handshake phase, Feeding the whole "flight" already waiting in network buffers into the TLS stack at once will no longer be possible, with hidden ContentTypes I will have to start trickling TLS records with handshake messages into the TLS stack, and have to poll the handshake state after each TLS record in order to heuristically determine whether the next record waiting in the network buffer is (likely) a record with AppData--which I must leave in the network buffer until the application caller explicitly calls for it. The really painful issue are constantly mind-changing browsers loosing interest in responses and sending TLS CloseNotify instead of TCP RSTs -- I don't know how to deal with these without breaking the current (network socket) event semantics for the app. -Martin From nobody Wed Nov 9 02:25:48 2016 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 2B4FF12996D for ; Wed, 9 Nov 2016 02:25:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 HiC6acw-nJ7C for ; Wed, 9 Nov 2016 02:25:44 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 A692612959D for ; Wed, 9 Nov 2016 02:25:44 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id i145so108212205ywg.2 for ; Wed, 09 Nov 2016 02:25:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CijFGCR65A4SnAeZzvRJogBe8LMOUaitivWzkrez8g0=; b=H7YQohWGCwl+rxtalCEcww6CmVyptgyNG9nJpV5jGCy/VBpnXj5N+cGIt4X2YA1jgu 0bsh5qG/SXSDCD/My3vxRfdL0WawejwoyibD3pOXQw3ce9HXmz8u35jblYQBc2+e+qz3 aMKbszGx4KQ2BjRSVwlDi2dhUcLUF9RwQOV0IRiOZC/srF843cyu8FmZuoLvhEGhk55L pauBx4L8ONVFUdD7wKmd/fbyZFRVe9Ge9xsbrR78/Tcs2mWDH3pA9eC4DVJrY0oyLkFr KnzRvdSkb3UJ6RLRi8m2XmMj+vWGjygRxxgtb8mEUlwwnI83Nr9LiRer0YVxoRJjmzAP gloQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CijFGCR65A4SnAeZzvRJogBe8LMOUaitivWzkrez8g0=; b=fZcuSqvTkv3+5M7UcUcZwpevM8+/1J1O5QNgxw0iCHtLu7pDCLRnrblPabdLMx47VE McAC5MET83K5Y8rqzzic5tIN5qpLEiyUkIG7DkJTZ9LUjpvM4d3PBDC2MmKC5OB3k4e5 ME0yBLPLEtS3Bjp3VTzqa2iIw5pEi/CKOu0Wd0SeNgzyS9vipqf6MplQ1pTJv23BOjkC 3W+p8cAnH2DATtfNUns/zMF95W9UsnA8kGn7+GM2+OPD+tEpny2gvH1sQahkkNAkFv6T 2EgLO5Me9Q0fPn1iacT5J+FwyCF3DEoEz2ifyiK2BAoCUAwn92QwzM2M7PFdr3r2ZMYk EgQw== X-Gm-Message-State: ABUngvfzWZgQ0QKgWoy20F/LzwiE7Cx/gs55S/F6SfNKsUvN33FTCvjyuZQo3xRSZwpjLfXBTaW9MQPOK3sfuQ== X-Received: by 10.129.125.215 with SMTP id y206mr15425206ywc.234.1478687143849; Wed, 09 Nov 2016 02:25:43 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Wed, 9 Nov 2016 02:25:03 -0800 (PST) In-Reply-To: <20161109093122.6D3111A579@ld9781.wdf.sap.corp> References: <61800c8dd50f4a1a911f8f2c96b65dda@usma1ex-dag1mb1.msg.corp.akamai.com> <20161109093122.6D3111A579@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Wed, 9 Nov 2016 02:25:03 -0800 Message-ID: To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=001a11492dfaf1a2580540dbada2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 09 Nov 2016 10:25:47 -0000 --001a11492dfaf1a2580540dbada2 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 9, 2016 at 1:31 AM, Martin Rex wrote: > Salz, Rich wrote: > >> the PDUs are still pretty much predictable > >> heuristically (by their ordering), even when they're padded. > > > > ... > > > >> So besides being completely pointless, can you describe any realistic > >> problem that is worth breaking middleware at the endpoints so badly? > > > > I found the language difference interesting. We could conduct an > > interesting thought experiment by reversing the emphasis on each > > of the above fragments. But I won't. > > > > Instead, I'll point out that this is in-charter, in-scope, and WG > consensus > > has generally been to "encrypt all the bits" as much as feasible. > > The problem here is that this breaks (network) flow control, existing > (network socket) event management, and direction-independent connection > closure, and does so completely without value. > > When TLS records with AppData can be left in the network socket while > the application layer is not ready to process & consume it, then TCP flow > control works better in high load situation. > > > The semantics defined for the TLS Closure Alert in SSLv3->TLSv1.2 > is somewhat difficult for full-duplex communication, direction-independent > shutdown, and confirmation of receipt: > > https://tools.ietf.org/html/rfc5246#section-7.2.1 > > 7.2.1. Closure Alerts > > The client and the server must share knowledge that the connection is > ending in order to avoid a truncation attack. Either party may > initiate the exchange of closing messages. > > close_notify > This message notifies the recipient that the sender will not send > any more messages on this connection. Note that as of TLS 1.1, > failure to properly close a connection no longer requires that a > session not be resumed. This is a change from TLS 1.0 to conform > with widespread implementation practice. > > Either party may initiate a close by sending a close_notify alert. > Any data received after a closure alert is ignored. > > Unless some other fatal alert has been transmitted, each party is > required to send a close_notify alert before closing the write side > of the connection. The other party MUST respond with a close_notify > alert of its own and close down the connection immediately, > discarding any pending writes. It is not required for the initiator > of the close to wait for the responding close_notify alert before > closing the read side of the connection. > > > The issue here is that the receiving TLS stack, when processing an > incoming TLS CloseNotify Alert, will typically immediately respond > with a TLS CloseNotifyAlert on its own, precluding the application > from sending any further data in the other direction in response > > When hiding the TLS record ContentType, then pre-reading and coalescing > (=streaming) application data records suddenly becomes a problem, because > receiving and processing a hidden TLS CloseNotify Alert will cause > a TLS CloseNotify Alert response (an alleged indicator for a graceful > connection closure) being generated and returned even before > the application has (a) seen and (b) had a chance to respond to the > latest batch of application data. > > > To prevent this from happening, and leave the decision to the application > of whether to read a (potential) CloseNotify alert from the wire, > I would have to go back to trickling TLS records (including those > pathologically fragmented ones from Google) to the application > whenever TLSv1.3 is negotiated. > I'm not quite following who's who in this scenario, so some potentially stupid questions below. As I understand it, you have the following situation: - A Web application server - Some middleware, which comes in two pieces - A crypto-unaware network component - The TLS stack (you control this piece as well, right?) - The client So, in this case, the client sends a flight of records which (ignoring rehandshakes and other TLS 1.3 post-handshake shenanigans such as KeyUpdate) contains a bunch of application data traffic potentially terminating in a close_notify. In TLS 1.2 you inspect the content type, deliver all the app data to the TLS processor, but hold the close_notify. And those packets are in turn handed to the Web server/application. Is that correct? If so, when do you deliver the close_notify and how do you know how? In the TLS 1.3 case, as I understand it, you can't see which packets are which so you just have to deliver all the packets to the TLS processor, and if one of them contains a close_notify, then it responds with its own close_notify (I'm getting this from the text above where you say "being generated and returned even before the application has..."). Is that right as well? Can you explain further why this is a problem: are you expecting that if you send application data to the client after sending the close_notify itself, the client will consume it? Or are we somehow concerned with side effects on the application server? Can you help me understand? thanks, -Ekr There is a similar (slightly smaller) issuer with the coalesced TLS > handshake/alert/css record processing during the TLS handshake phase, > Feeding the whole "flight" already waiting in network buffers into > the TLS stack at once will no longer be possible, with hidden ContentTypes > I will have to start trickling TLS records with handshake messages into > the TLS stack, and have to poll the handshake state after each TLS record > in order to heuristically determine whether the next record waiting in > the network buffer is (likely) a record with AppData--which I must leave > in the network buffer until the application caller explicitly calls for it. > > > The really painful issue are constantly mind-changing browsers loosing > interest in responses and sending TLS CloseNotify instead of TCP RSTs > -- I don't know how to deal with these without breaking the current > (network socket) event semantics for the app. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11492dfaf1a2580540dbada2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 9, 2016 at 1:31 AM, Martin Rex <mrex@sap.com> wro= te:
Salz, Rich w= rote:
>> the PDUs are still pretty much predictable
>> heuristically (by their ordering), even when they're padded. >
> ...
>
>> So besides being completely pointless, can you describe any realis= tic
>> problem that is worth breaking middleware at the endpoints so badl= y?
>
> I found the language difference interesting.=C2=A0 We could conduct an=
> interesting thought experiment by reversing the emphasis on each
> of the above fragments.=C2=A0 But I won't.
>
> Instead, I'll point out that this is in-charter, in-scope, and WG = consensus
> has generally been to "encrypt all the bits" as much as feas= ible.

The problem here is that this breaks (network) flow control, existin= g
(network socket) event management, and direction-independent connection
closure, and does so completely without value.

When TLS records with AppData can be left in the network socket while
the application layer is not ready to process & consume it, then TCP fl= ow
control works better in high load situation.


The semantics defined for the TLS Closure Alert in SSLv3->TLSv1.2
is somewhat difficult for full-duplex communication, direction-independent<= br> shutdown, and confirmation of receipt:

=C2=A0 =C2=A0https://tools.ietf.org/html/rfc52= 46#section-7.2.1

=C2=A0 =C2=A07.2.1.=C2=A0 Closure Alerts

=C2=A0 =C2=A0The client and the server must share knowledge that the connec= tion is
=C2=A0 =C2=A0ending in order to avoid a truncation attack.=C2=A0 Either par= ty may
=C2=A0 =C2=A0initiate the exchange of closing messages.

=C2=A0 =C2=A0close_notify
=C2=A0 =C2=A0 =C2=A0 This message notifies the recipient that the sender wi= ll not send
=C2=A0 =C2=A0 =C2=A0 any more messages on this connection.=C2=A0 Note that = as of TLS 1.1,
=C2=A0 =C2=A0 =C2=A0 failure to properly close a connection no longer requi= res that a
=C2=A0 =C2=A0 =C2=A0 session not be resumed.=C2=A0 This is a change from TL= S 1.0 to conform
=C2=A0 =C2=A0 =C2=A0 with widespread implementation practice.

=C2=A0 =C2=A0Either party may initiate a close by sending a close_notify al= ert.
=C2=A0 =C2=A0Any data received after a closure alert is ignored.

=C2=A0 =C2=A0Unless some other fatal alert has been transmitted, each party= is
=C2=A0 =C2=A0required to send a close_notify alert before closing the write= side
=C2=A0 =C2=A0of the connection.=C2=A0 The other party MUST respond with a c= lose_notify
=C2=A0 =C2=A0alert of its own and close down the connection immediately, =C2=A0 =C2=A0discarding any pending writes.=C2=A0 It is not required for th= e initiator
=C2=A0 =C2=A0of the close to wait for the responding close_notify alert bef= ore
=C2=A0 =C2=A0closing the read side of the connection.


The issue here is that the receiving TLS stack, when processing an
incoming TLS CloseNotify Alert, will typically immediately respond
with a TLS CloseNotifyAlert on its own, precluding the application
from sending any further data in the other direction in response

When hiding the TLS record ContentType, then pre-reading and coalescing
(=3Dstreaming) application data records suddenly becomes a problem, because=
receiving and processing a hidden TLS CloseNotify Alert will cause
a TLS CloseNotify Alert response (an alleged indicator for a graceful
connection closure) being generated and returned even before
the application has (a) seen and (b) had a chance to respond to the
latest batch of application data.


To prevent this from happening, and leave the decision to the application of whether to read a (potential) CloseNotify alert from the wire,
I would have to go back to trickling TLS records (including those
pathologically fragmented ones from Google) to the application
whenever TLSv1.3 is negotiated.

I'm= not quite following who's who in this scenario, so some potentially st= upid
questions below.

As I understand it= , you have the following situation:

- A Web applic= ation server
- Some middleware, which comes in two pieces
=C2=A0 - A crypto-unaware network component
=C2=A0 - The TLS s= tack (you control this piece as well, right?)
- The client
<= div>
So, in this case, the client sends a flight of records w= hich (ignoring rehandshakes
and other TLS 1.3 post-handshake shen= anigans such as KeyUpdate) contains
a bunch of application data t= raffic potentially terminating in a close_notify. In
TLS 1.2 you = inspect the content type, deliver all the app data to the TLS processor,
but hold the close_notify. And those packets are in turn handed to = the Web
server/application. Is that correct? If so, when do you d= eliver the close_notify
and how do you know how?

In the TLS 1.3 case, as I understand it, you can't see which p= ackets are which
so you just have to deliver all the packets to t= he TLS processor, and if one of
them contains a close_notify, the= n it responds with its own close_notify
(I'm getting this fro= m the text above where you say "being generated and
returned= even before the application has..."). Is that right as well? Can you = explain
further why this is a problem: are you expecting that if = you send application
data to the client after sending the close_n= otify itself, the client will consume
it? Or are we somehow conce= rned with side effects on the application server?

= Can you help me understand?

thanks,
-Ekr=





=



There is a similar (slightly smaller) issuer with the coalesced TLS
handshake/alert/css record processing during the TLS handshake phase,
Feeding the whole "flight" already waiting in network buffers int= o
the TLS stack at once will no longer be possible, with hidden ContentTypes<= br> I will have to start trickling TLS records with handshake messages into
the TLS stack, and have to poll the handshake state after each TLS record in order to heuristically determine whether the next record waiting in
the network buffer is (likely) a record with AppData--which I must leave in the network buffer until the application caller explicitly calls for it.=


The really painful issue are constantly mind-changing browsers loosing
interest in responses and sending TLS CloseNotify instead of TCP RSTs
-- I don't know how to deal with these without breaking the current
(network socket) event semantics for the app.
=

-Martin

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a11492dfaf1a2580540dbada2-- From nobody Wed Nov 9 09:07:16 2016 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 6ADAA12946E for ; Wed, 9 Nov 2016 09:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no 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 foCacL14kVcO for ; Wed, 9 Nov 2016 09:07:11 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118]) by ietfa.amsl.com (Postfix) with ESMTP id 7FA721294BB for ; Wed, 9 Nov 2016 09:07:11 -0800 (PST) Received: from fifthhorseman.net (unknown [148.204.216.119]) by che.mayfirst.org (Postfix) with ESMTPSA id 1885AF98C; Wed, 9 Nov 2016 12:07:09 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 2DBCA20955; Wed, 9 Nov 2016 11:05:30 -0600 (CST) From: Daniel Kahn Gillmor To: mrex@sap.com, "Salz\, Rich" In-Reply-To: <20161109093122.6D3111A579@ld9781.wdf.sap.corp> References: <20161109093122.6D3111A579@ld9781.wdf.sap.corp> Date: Wed, 09 Nov 2016 11:05:27 -0600 Message-ID: <87inrweg88.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 09 Nov 2016 17:07:13 -0000 --=-=-= Content-Type: text/plain On Wed 2016-11-09 03:31:22 -0600, Martin Rex wrote: > The problem here is that this breaks (network) flow control, existing > (network socket) event management, and direction-independent connection > closure, and does so completely without value. Martin, you keep saying things like "without value", while other people on this thread (Rich, Ilari, Yoav) have given you examples of the value it provides. You don't seem to be trying to understand those positions. Your description of the problems it causes you are difficult to follow, and it doesn't sound like they have been experienced by other implementors. But other people are actively trying to make sure they understand your concerns (like ekr's post downthread here). Could you offer the rest of the list the same courtesy? Your earlier argument that the hidden data is deducable by traffic analysis anyway isn't a satisfying argument, for two reasons: (a) if it were reliably true, then your implementations could simply adopt the traffic analysis approach instead of inspecting the cleartext content types. If it causes too much additional expense, then it should increase the expense for adversaries who are monitoring traffic for these same signals as well, which is a security+privacy win. (b) We're including mechanisms (like padding) to make traffic analysis harder. More research is needed to know how to best provide this sort of indistinguishability. But if we decide instead that it's ok to directly publish any data that could possibly be inferred by traffic analysis, we will never improve the security of TLS for its users against traffic analysis, which will only grow more sophisticated over time. Why should we accept this limitation on TLS? This WG isn't chartered to defend the engineering optimizations made by any particular middlebox vendor. It's chartered to improve the privacy and security guarantees offered to users of TLS. Regards, --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQJ8BAEBCgBmBQJYI1dXXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKJTsP/0MQx9ftB2WG4G4DH1+Ih2XN aTL8cDZkfrpXrMWXd0PU57qGK10HuIIhrelLJ38jwBNGzoXtteA//aVlaskgnYUX oEfH1t+9Bt3mOcqc0ydMKV27hwWzCji1vd2paerp5PhX8ZduZaBkQqaFE+zctnmH QKxOYFXVkDr9/ONwo059Xu1dj19FYqgjzHpz3wH4NQQyQebxVnqSgjYFjxULpcyL E30ZIthHLa8Trgb68+bFUVrSgLG2GUZaWo8NQDCXTFei9SiQrBI7YvVuOlmou2h2 IhaKn3hSF5cYDL3Yb3Qlm7D6yo/Sp9W7M2WO6aq3KTliVQ1rG8hXsUJcMA5zuUm7 k1JgyipQaitHQFb4vHhx0T7wVcyuMIOXyENUppzTY7zVqMXLpLd5Jh4iz9NUq5Vf ti/bNSTDhDgTolwKjOnNhMP2YN8/1v9M8tHkBcCfNGSahCOYPq3VHJLWlvK2QayW bdkKO2qt+EysFUTVQHHUTu3KN4nR2U1RcxvXXrcZuOM0guRffdXhS3Yvu6BLu/U1 Ib7ML8jgmqjG30ozqGU+S8hCQ5C3mEUrRF7WfqW2Qd8CFyRdgZZ4agSjCB6x+QL1 tRY17uU0q7bN9tp6jLnG2rvE3pPm6JoLtXigBkWitmBJorCLpgBnyjxZZdiKu/Pz bDAzECXI/tLq9nrmJnJK =XMjm -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 9 09:43:02 2016 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 272ED1296C4 for ; Wed, 9 Nov 2016 09:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 msy9-VLzkQSs for ; Wed, 9 Nov 2016 09:42:22 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0607B129581 for ; Wed, 9 Nov 2016 09:42:21 -0800 (PST) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3tDYQz5kVTz1Ht7; Wed, 9 Nov 2016 18:42:19 +0100 (CET) X-purgate-ID: 152705::1478713339-0000521C-E30AE6C8/0/0 X-purgate-size: 1685 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3tDYQz2KvGzGntL; Wed, 9 Nov 2016 18:42:19 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 454D21A579; Wed, 9 Nov 2016 18:42:19 +0100 (CET) In-Reply-To: <87inrweg88.fsf@alice.fifthhorseman.net> To: Daniel Kahn Gillmor Date: Wed, 9 Nov 2016 18:42:19 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161109174219.454D21A579@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Wed, 09 Nov 2016 17:42:24 -0000 Daniel Kahn Gillmor wrote: > > Martin Rex wrote: >> >> The problem here is that this breaks (network) flow control, existing >> (network socket) event management, and direction-independent connection >> closure, and does so completely without value. > > Martin, you keep saying things like "without value", while other people > on this thread (Rich, Ilari, Yoav) have given you examples of the value > it provides. You don't seem to be trying to understand those positions. Nobody so far has provide a single example of *REAL* value. For the hiding of ContentType to provide real value, the prerequisites are: (1) this value will be _unconditionally_ provided in TLSv1.3 (2) this value can be demonstrated to be a real security issue in TLSv1.2, for existing usage scenarios, where hiding of ContentType is not available Anyhing less is no value, just an illusion of value. > > This WG isn't chartered to defend the engineering optimizations made by > any particular middlebox vendor. It's chartered to improve the privacy > and security guarantees offered to users of TLS. You are confusing _middlebox_ with _middleware_at_the_endpoint_, which is a huge difference, because the middleboxes are performing man-in-the-middle attacks, whereas the _middleware_at_the_endpoint_ has regular access to the entire plaintext of the communication. The problem with hiding of TLS record ContentTypes is that it severely interferes with efficient streaming network I/O--which is preferably performed outside/above the TLS implementation and async non-blocking whenever you get into thousands of parallel connections. -Martin From nobody Wed Nov 9 09:58:18 2016 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 C6A4B12711D for ; Wed, 9 Nov 2016 09:58:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYkUmXahL0MI for ; Wed, 9 Nov 2016 09:58:10 -0800 (PST) Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 21421126579 for ; Wed, 9 Nov 2016 09:58:10 -0800 (PST) Received: by mail-vk0-x234.google.com with SMTP id p9so182421415vkd.3 for ; Wed, 09 Nov 2016 09:58:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=hDFpXzhn0f4JjxgmuutgWSHbvr/afNSsU5kedVE4pao=; b=wVjiHu3+yDBi5xboNmRZUxZBZ+C87eHB0BnAvi2K4b6v8FaJsABuYhwDsjQDFif4l6 8CWb/vvFhs6xzNfcWZxJhGX1A+6gWD91mrRwe1vXRfj+P8KeAnYU+31m0LFaxvdEVR+9 G+YV14bfE9fDLwh+017PbscAXft1Tjn1FjdG+/IRmbRxlFAkx4jQs8qhfqAMA3BIaDYS 3jsXhxuvKi9SkbOUm3+4CkXxonhStRhwi5u4Mxmj1fYTWF1G8vcHH2hCz2Q9fdb3A7u7 MXYmNrYBjnGgKUnOo1SnPDJevGEbFGmEByQxQZjcu6EcEfc4kyQLbTdy58f6j4n4QZYR 6+7g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=hDFpXzhn0f4JjxgmuutgWSHbvr/afNSsU5kedVE4pao=; b=aFsR1sKK80v44ROdEv3fn2csq7m23WitDmcSaZaKEJSU0Yg8clq3DuYUr2uOmcZt/t RDHL3b6oWX1z3XLFqWFpBYcMya3L8TPZ5sVwPUE2L+nLu3iRyRae7HkFQhApes7XNICS 2A8evMAr9ZI91eAcaEJsOye8w4q4T5YByMgqwt1caRNxZaO0Ac1AWiCyrA7HaJ2m5SHK doMGI+RgJttoFeTJDuerGLL6s4LuNEU5+PL7O2EHoFto5XBAq1zEpcve04SiR5QsRzw9 c58KkDkZbmYCbYXsZh5C7mwvMi9pvTdLCZaIV/vvcHXcyWpVRfxdhjq3+C0tq5P2QcIB tpcg== X-Gm-Message-State: ABUngveSVbGUV1g00eD8nJxSmBwbmZzrAGn7v17BPe0YWnX3JuHUi+cQWoWZy2Ts/KBxdALCKQLxAJgXh3mDwg== X-Received: by 10.31.178.66 with SMTP id b63mr605307vkf.70.1478714289150; Wed, 09 Nov 2016 09:58:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Wed, 9 Nov 2016 09:58:08 -0800 (PST) Received: by 10.176.85.18 with HTTP; Wed, 9 Nov 2016 09:58:08 -0800 (PST) In-Reply-To: <20161109174219.454D21A579@ld9781.wdf.sap.corp> References: <87inrweg88.fsf@alice.fifthhorseman.net> <20161109174219.454D21A579@ld9781.wdf.sap.corp> From: Watson Ladd Date: Wed, 9 Nov 2016 09:58:08 -0800 Message-ID: To: mrex@sap.com Content-Type: multipart/alternative; boundary=001a11439232ede74e0540e1ff40 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 09 Nov 2016 17:58:17 -0000 --001a11439232ede74e0540e1ff40 Content-Type: text/plain; charset=UTF-8 On Nov 9, 2016 9:43 AM, "Martin Rex" wrote: > > Daniel Kahn Gillmor wrote: > > > > Martin Rex wrote: > >> > >> The problem here is that this breaks (network) flow control, existing > >> (network socket) event management, and direction-independent connection > >> closure, and does so completely without value. > > > > Martin, you keep saying things like "without value", while other people > > on this thread (Rich, Ilari, Yoav) have given you examples of the value > > it provides. You don't seem to be trying to understand those positions. > > Nobody so far has provide a single example of *REAL* value. > For the hiding of ContentType to provide real value, the prerequisites are: > > (1) this value will be _unconditionally_ provided in TLSv1.3 > > (2) this value can be demonstrated to be a real security issue in TLSv1.2, > for existing usage scenarios, where hiding of ContentType is not > available > > Anyhing less is no value, just an illusion of value. > > > > > > This WG isn't chartered to defend the engineering optimizations made by > > any particular middlebox vendor. It's chartered to improve the privacy > > and security guarantees offered to users of TLS. > > You are confusing _middlebox_ with _middleware_at_the_endpoint_, > which is a huge difference, because the middleboxes are performing > man-in-the-middle attacks, whereas the _middleware_at_the_endpoint_ > has regular access to the entire plaintext of the communication. > > The problem with hiding of TLS record ContentTypes is that it severely > interferes with efficient streaming network I/O--which is preferably > performed outside/above the TLS implementation and async non-blocking > whenever you get into thousands of parallel connections. No one else has reported this. That's including Microsoft whose implementation does hand over all IO to the application. Absent many more details you are not convincing me there is a problem. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a11439232ede74e0540e1ff40 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Nov 9, 2016 9:43 AM, "Martin Rex" <mrex@sap.com> wrote:
>
> Daniel Kahn Gillmor wrote:
> >
> > Martin Rex wrote:
> >>
> >> The problem here is that this breaks (network) flow control, = existing
> >> (network socket) event management, and direction-independent = connection
> >> closure, and does so completely without value.
> >
> > Martin, you keep saying things like "without value", wh= ile other people
> > on this thread (Rich, Ilari, Yoav) have given you examples of the= value
> > it provides.=C2=A0 You don't seem to be trying to understand = those positions.
>
> Nobody so far has provide a single example of *REAL* value.
> For the hiding of ContentType to provide real value, the prerequisites= are:
>
> =C2=A0 (1) this value will be _unconditionally_ provided in TLSv1.3 >
> =C2=A0 (2) this value can be demonstrated to be a real security issue = in TLSv1.2,
> =C2=A0 =C2=A0 =C2=A0 for existing usage scenarios, where hiding of Con= tentType is not
> =C2=A0 =C2=A0 =C2=A0 available
>
> Anyhing less is no value, just an illusion of value.
>
>
> >
> > This WG isn't chartered to defend the engineering optimizatio= ns made by
> > any particular middlebox vendor.=C2=A0 It's chartered to impr= ove the privacy
> > and security guarantees offered to users of TLS.
>
> You are confusing _middlebox_ with _middleware_at_the_endpoint_,
> which is a huge difference, because the middleboxes are performing
> man-in-the-middle attacks, whereas the _middleware_at_the_endpoint_ > has regular access to the entire plaintext of the communication.
>
> The problem with hiding of TLS record ContentTypes is that it severely=
> interferes with efficient streaming network I/O--which is preferably > performed outside/above the TLS implementation and async non-blocking<= br> > whenever you get into thousands of parallel connections.

No one else has reported this. That's including Microsof= t whose implementation does hand over all IO to the application. Absent man= y more details you are not convincing me there is a problem.

>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a11439232ede74e0540e1ff40-- From nobody Wed Nov 9 11:42:17 2016 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 E3F221296E4 for ; Wed, 9 Nov 2016 11:42:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 baU1Un7HP3j6 for ; Wed, 9 Nov 2016 11:42:14 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D2521296BA for ; Wed, 9 Nov 2016 11:42:13 -0800 (PST) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3tDc5H1ChTz25Wb; Wed, 9 Nov 2016 20:42:11 +0100 (CET) X-purgate-ID: 152705::1478720531-00002B31-EEA28E40/0/0 X-purgate-size: 7008 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3tDc5G4SjCzGnv0; Wed, 9 Nov 2016 20:42:10 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 8ED431A579; Wed, 9 Nov 2016 20:42:10 +0100 (CET) In-Reply-To: To: Eric Rescorla Date: Wed, 9 Nov 2016 20:42:10 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161109194210.8ED431A579@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Wed, 09 Nov 2016 19:42:16 -0000 Eric Rescorla wrote: > > I'm not quite following who's who in this scenario, so some potentially > stupid > questions below. > > As I understand it, you have the following situation: > > - A Web application server > - Some middleware, which comes in two pieces > - A crypto-unaware network component > - The TLS stack (you control this piece as well, right?) > - The client This is about any conceivable scenario involving at least one of our components, just client, just server, or at both peers. The "middleware" is part of our clients and servers. The middleware performs all the network I/O and necessary calls into the TLS stack, offers an appdata streaming convenience option for reading, variable blocking I/O (non-blocking (0ms) up to infinite timeout). TLS records of type Handshake, Alert and CCS are always processed in batch, as many as the network buffers have already received. TLS records of type AppData are processed based on read strategy desired by the application caller. The desired reading strategy (trickling, efficient, streaming) is a parameter of the middleware read API call, so the app could change it for every call. - Trickling means the traditional TLS record reading, i.e. two network read calls for every TLS record. - Improved means on average one network read call per TLS record. - Streaming means reading and decoding as many TLS appdata record as there are present in the network read buffers and can be received non-blocking. Only TLS AppData records will be passed to the TLS Stack for decoding, Alerts and Handshake records will be left in the middlewares network read buffers until all appdata as been properly received by the application caller. Only upon the next read call from the application, the alert or handshake records will be passed to the TLS stack. Example: GET https://www.google.de/ HTTP/1.0 (where my call to www.google.com is redirected to...) currently returns a HTTP-response with a 657 byte Header and 44879 byte Body The response would easily fit into 3 TLS appdata records (4 Records if the Header is sent in its own TLS record), however in reality, the Google servers perform pathological fragmentation of the AppData and use a whooping 36 TLS records for the response (curiously no TLS AppData record split between header and body). Processing overhead for _receiving_ such a badly fragmented response: Trickling: 34 Read calls into the middleware 73 recv() calls to read the TLS AppData records from the socket 34 calls into the TLS stack Improved: 34 Read calls into the middleware 42 recv() calls to read the TLS AppData records from the socket 34 calls into the TLS stack Streaming: 5 Read calls into the middleware 14 recv() calls to read the TLS AppData records from the socket 34 calls into the TLS stack > > When do you deliver the close_notify and how do you know how? When the application calls for read, and has already seen all prior AppData, then the close_notify will be processed and the result (connection closure, no more data) reported to the calling app. There is no magic involved here. Apps *know* when to perform reads, and when not to perform reads. The middleware doesn't because it is protocol ignorant (it is used by SMTP, ldaps, HTTPS, HTTP/2.0, websockets, etc). Think of a simple HTTP-based server app receiving a HTTP/1.0 request from a TLS-stack on top of a blocking network socket. If the App would keep calling SSL_read() (for an OpenSSL-style API), it would get stuck (blocked on read), and at some point the client would give up and close the connection (with close_notify or TCP RST), and the server waking from either the processing of the close_notify or the TCP RST would be unable to deliver a response (which the client would not read anyway). Whether or not the calling App wants to shutdown a communication at different times in both directions depends on the existing semantics of that application (which has just added TLS protection around its communication). Reading and processing a close_notify in the TLS stack (e.g. OpenSSL) will tear down *BOTH* directions immediately, and preclude any further of sending of responses by the application, so the middleware really will want to hold of processing of close_notify alerts unless _explicitly_ asked to read further AppData by the application. With TLS up to TLSv1.2 streaming is no problem, the middleware can easily recognize non-AppData records and avoid passing them to the TLS stack for processing unless the application explicitly asks the middleware to do so. When TLSv1.3 hides the ContentType, the fact that a close_notify was received & processed can only be determined after the fact, when the shattered pieces are on the floor. Communication in the other direction will be impossible, and it will not be possible to prevent this from happening. While it is conceivable to jump hoops and implement new APIs and callback for the TLS stack to allow the middleware instrumenting and holding off the processing of TLS close_notify, this is not going to allow a drop-in replacement of an existing TLSv1.2 with a ContentType-hiding TLSv1.3 implementation underneath an existing application. For SSLv3->TLSv1.2, there was *NO* such backwards-incompatibilty. We were able just fine to drop-in a TLSv1.2 implementation underneath apps that were originally built on top of an SSLv3-only stack. > > Can you explain further why this is a problem: are you expecting that > if you send application data to the client after sending the close_notify > itself, the client will consume it? > > Can you help me understand? TCP is a full-duplex communication channel and allows shutdown for each of the two communication directions performed independently. There are existing communication protocols (other than HTTP) that _use_ independent shutdown, and may want to continue using it even after starting to protect their original cleatext communication with TLS. If you're vaguely familiar with OpenSSL: when SSL_read() has received and processed a TLS record with a close_notify alert, do you know what happens to further calls of SSL_write() of the same handle, which technically is _the_other_ communication direction. If you don't know: SSL_write() will fail, because OpenSSL will push out a close_notify alert from within SSL_read(), and make the connection unusable. Being able to distinguish AppData records from non-AppData records, an application caller of SSL_read() (such as my middleware) can prevent loosing the backchannel with no prior warning -- if it wants to. For streaming operation, my middleware DESPERATELY wants to prevent the communication channel becoming unusable in both directions _before_ the application has received/seen all the app data from the channel. -Martin From nobody Wed Nov 9 12:22:25 2016 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 3D87B1293E0 for ; Wed, 9 Nov 2016 12:22:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkRVxqlJ7tcK for ; Wed, 9 Nov 2016 12:22:23 -0800 (PST) Received: from mail-it0-x234.google.com (mail-it0-x234.google.com [IPv6:2607:f8b0:4001:c0b::234]) (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 AA2701294CF for ; Wed, 9 Nov 2016 12:22:22 -0800 (PST) Received: by mail-it0-x234.google.com with SMTP id u205so296421792itc.0 for ; Wed, 09 Nov 2016 12:22:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=blxvcfMTQduzvoKQkoupvnz0AAwFGa0r+ZjsID/8OZg=; b=ge+LGw91rHsopUBsoMBgJyN4ErmgiHEEjTHALRhZGJVbSIewqLdhTVVzCuA85Jyn9G wkXWusDW14wrUc9YG+hlSHAfNZV8BgMw2G6FwLfIJEb8XmHj3ydVpKsZO5z7e9CVQqz4 0HsVcHi/g4EaKf9dPNeeuw79y0nJg4FPYWKmDYnJRph/ffExA6Sqdm9oq+na61nXAgLh sSsw53OnPJN22U3hUcWAGyj+ho7UepCr9EWnupp/pVwuCTvOMKsobbiv2+AHcPyLgbeZ BctDnzRjvKiVx7IMSGMmS0/iOI4MwcdAvJgJ2vMfGFK2vDq37GUIDzWfk7NjIEx8cZlJ Ij5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=blxvcfMTQduzvoKQkoupvnz0AAwFGa0r+ZjsID/8OZg=; b=FLfcPJYbStLmoa++kqf+hcWr+XBs5w1WFucyNMT109B2nbhePdFCOfznOlwGooX7Pd 0IH0jTcO8JjQc0H3DerRcoF1CHg8DkS9lU2zy+Jq110MsBJAGsIvo99S5r8hhCCu5y0J n9ouQum7xDn8NvXp4F3GhDlIM+Y2BTJ7Yf9qj+7xP9JKmUMgy+BYrFFCeHjY2jB8Fo+c YTH/TNzlMScZKHYelu5vdKfRtEzH6z2vnsNpm9Go9Ey+uWCQ9ndLoYq7EV/AlRR6068a GGT6qme3Rz9xA86nwao8j9uMYbGsmjZzde4DtvVqbGLgz1DOZDiBd3JeQETpWeMEjSZG gx+Q== X-Gm-Message-State: ABUngveHMZ65F6Wkip34QflDgMu2dbzczkRwXQC67YZePHpomu+0t079+t/QQhj+xc27mRApJDo5TORTaoAOOQ== X-Received: by 10.107.199.66 with SMTP id x63mr2236391iof.97.1478722941768; Wed, 09 Nov 2016 12:22:21 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.36.104.69 with HTTP; Wed, 9 Nov 2016 12:22:20 -0800 (PST) In-Reply-To: <20161109194210.8ED431A579@ld9781.wdf.sap.corp> References: <20161109194210.8ED431A579@ld9781.wdf.sap.corp> From: Adam Langley Date: Wed, 9 Nov 2016 12:22:20 -0800 X-Google-Sender-Auth: 0muLa33uLykrs0Q7OQk7RsFuNE4 Message-ID: To: mrex@sap.com Content-Type: multipart/alternative; boundary=94eb2c0476a6aa5a310540e403c7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 09 Nov 2016 20:22:25 -0000 --94eb2c0476a6aa5a310540e403c7 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 9, 2016 at 11:42 AM, Martin Rex wrote: > in reality, the Google servers perform pathological fragmentation > of the AppData and use a whooping 36 TLS records for the response > (curiously no TLS AppData record split between header and body). > At the beginning of a connection we aim to size TLS records so that they don't span packets. Since none of a TLS record can be processed until the whole record is received, spanning packets can mean spanning TCP windows or loss events and thus add significant latency. Web browsers will shallow-parse data as it arrives in order to start subresource fetches as soon as possible, so delays can have a cascading effect. See also https://hpbn.co/transport-layer-security-tls/#optimize-tls-record-size. If you download a lot of data on a connection (i.e. some MBs) then you should find the the record sizes adjust to optimise for throughput. Cheers AGL --94eb2c0476a6aa5a310540e403c7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 9, 2016 at 11:42 AM, Martin Rex <mrex@sap.com> wrote:
=
in reality, the Google se= rvers perform pathological fragmentation
of the AppData and use a whooping 36 TLS records for the response
(curiously no TLS AppData record split between header and body).

At the beginning of a connection we aim to size T= LS records so that they don't span packets. Since none of a TLS record = can be processed until the whole record is received, spanning packets can m= ean spanning TCP windows or loss events and thus add significant latency. W= eb browsers will shallow-parse data as it arrives in order to start subreso= urce fetches as soon as possible, so delays can have a cascading effect. Se= e also=C2=A0https://hpbn.co/transport-layer-security-tls/#optimize-= tls-record-size.

If you download a lot of data= on a connection (i.e. some MBs) then you should find the the record sizes = adjust to optimise for throughput.


= Cheers

AGL=C2=A0
--94eb2c0476a6aa5a310540e403c7-- From nobody Wed Nov 9 14:07:55 2016 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 351FD1299BE for ; Wed, 9 Nov 2016 14:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-QmfZ1AbBFF for ; Wed, 9 Nov 2016 14:07:50 -0800 (PST) Received: from mail-vk0-x22c.google.com (mail-vk0-x22c.google.com [IPv6:2607:f8b0:400c:c05::22c]) (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 AB3FA129431 for ; Wed, 9 Nov 2016 14:07:50 -0800 (PST) Received: by mail-vk0-x22c.google.com with SMTP id p9so188126585vkd.3 for ; Wed, 09 Nov 2016 14:07:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mrK5ULr7V2KItPWn7p8QQ0/W4oHEmcTL4vMb8piVVSI=; b=XVoFyoYlgUjsxxgmBS87FzfPMGcnkeAC2HUJctCeXAjkB7nZAyQasMvezoDR9wz7he 7iX5Pak5O7EGYS5T5LxPTZdzKPwkgyciI90gTEa0J23CEs+N41B88JJXQA98JllIdNHm fuwNn7YyEbx+RVdxaCJm68lcOd7bpRvceT90qhErfrhENln5DtFdTcJ/JpAatZTcqGaH ODJ79cWBKFccVrY9uS0VT6y7KJByPZ8t/PrOHjYF9rqwDsHFa+z3DBgjv2ZMSBQwC7Y3 njGg8mfTqoN544ZP7G1QinaR8CF15jENFZTIjH+LWGwkmTJHsD0oAWPylMrGITVNukk5 ycyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mrK5ULr7V2KItPWn7p8QQ0/W4oHEmcTL4vMb8piVVSI=; b=Bmyet8ljO22qZmnDxOg9lp+xOh/pGFBg8jYeWcMBt0EFHwnEd7RkYFg/y7kbkF3Vbl 87N/v79spJrXk/TKuwRl8UMVSJB1oglokFh8Wg04qg6wr/xRexqRgFUO7DTW94gXStZN m0uhXqkldaNTjuQsrCApmrSqs7ZiVra0/Y9/GNVPeZrOZ2Z1F3PzRmmBTmHLfe000wYJ yUlvR439Nu5g5UNuzvSGBTbEJNVBHgECB5m/HiABL6cANN14UvLIE6jMuR61TYbTMf6P pJPOaNwdoe/CswGiJULokmj2s0UrLRRucT1pbO5uewdOuD9i6ebQi2ViYun2agJzO3Ky 0HaA== X-Gm-Message-State: ABUngveGyfbn/+E+NY3IktUwMTvzcLXYKlCquWNyRcYN4arS1kfZDEoSp+CmyKZaV2Kxr01UOj57dPfv0brtHw== X-Received: by 10.31.151.13 with SMTP id z13mr1373011vkd.41.1478729269752; Wed, 09 Nov 2016 14:07:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Wed, 9 Nov 2016 14:07:48 -0800 (PST) Received: by 10.176.85.18 with HTTP; Wed, 9 Nov 2016 14:07:48 -0800 (PST) In-Reply-To: <20161109194210.8ED431A579@ld9781.wdf.sap.corp> References: <20161109194210.8ED431A579@ld9781.wdf.sap.corp> From: Watson Ladd Date: Wed, 9 Nov 2016 14:07:48 -0800 Message-ID: To: mrex@sap.com Content-Type: multipart/alternative; boundary=001a1140fd58d7ba250540e57c8c Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 09 Nov 2016 22:07:54 -0000 --001a1140fd58d7ba250540e57c8c Content-Type: text/plain; charset=UTF-8 > > There is no magic involved here. > > Apps *know* when to perform reads, and when not to perform reads. > The middleware doesn't because it is protocol ignorant (it is used > by SMTP, ldaps, HTTPS, HTTP/2.0, websockets, etc). > > Think of a simple HTTP-based server app receiving a HTTP/1.0 request > from a TLS-stack on top of a blocking network socket. If the App would > keep calling SSL_read() (for an OpenSSL-style API), it would get stuck > (blocked on read), and at some point the client would give up and > close the connection (with close_notify or TCP RST), and the server > waking from either the processing of the close_notify or the TCP RST > would be unable to deliver a response (which the client would not read > anyway). This is an example of the application not knowing which channels are ready. So no the app doesn't "know when to read". > > Whether or not the calling App wants to shutdown a communication > at different times in both directions depends on the existing semantics > of that application (which has just added TLS protection around its > communication). Reading and processing a close_notify in the TLS stack > (e.g. OpenSSL) will tear down *BOTH* directions immediately, and preclude > any further of sending of responses by the application, so the middleware > really will want to hold of processing of close_notify alerts unless > _explicitly_ asked to read further AppData by the application. > > With TLS up to TLSv1.2 streaming is no problem, the middleware can > easily recognize non-AppData records and avoid passing them to > the TLS stack for processing unless the application explicitly asks > the middleware to do so. When TLSv1.3 hides the ContentType, > the fact that a close_notify was received & processed can only be > determined after the fact, when the shattered pieces are on the floor. > Communication in the other direction will be impossible, and it will > not be possible to prevent this from happening. > > While it is conceivable to jump hoops and implement new APIs and > callback for the TLS stack to allow the middleware instrumenting > and holding off the processing of TLS close_notify, this is not > going to allow a drop-in replacement of an existing TLSv1.2 with > a ContentType-hiding TLSv1.3 implementation underneath an existing > application. Yes, you will need to update the middleware component as well. Why is this a problem? > > For SSLv3->TLSv1.2, there was *NO* such backwards-incompatibilty. > We were able just fine to drop-in a TLSv1.2 implementation underneath > apps that were originally built on top of an SSLv3-only stack. > > > > > > > Can you explain further why this is a problem: are you expecting that > > if you send application data to the client after sending the close_notify > > itself, the client will consume it? > > > > Can you help me understand? > > TCP is a full-duplex communication channel and allows shutdown for each > of the two communication directions performed independently. There are > existing communication protocols (other than HTTP) that _use_ independent > shutdown, and may want to continue using it even after starting to > protect their original cleatext communication with TLS. > > > If you're vaguely familiar with OpenSSL: > when SSL_read() has received and processed a TLS record with a close_notify > alert, do you know what happens to further calls of SSL_write() of the same > handle, which technically is _the_other_ communication direction. Is this the case? Actually alerts trigger teardown of both sides. There is no half open state for TLS. Nginx manages fine on OpenSSL. > > If you don't know: SSL_write() will fail, because OpenSSL will push out > a close_notify alert from within SSL_read(), and make the connection > unusable. Being able to distinguish AppData records from non-AppData > records, an application caller of SSL_read() (such as my middleware) > can prevent loosing the backchannel with no prior warning -- if it > wants to. For streaming operation, my middleware DESPERATELY wants to > prevent the communication channel becoming unusable in both directions > _before_ the application has received/seen all the app data from the channel. > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a1140fd58d7ba250540e57c8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


>
> There is no magic involved here.
>
> Apps *know* when to perform reads, and when not to perform reads.
> The middleware doesn't because it is protocol ignorant (it is used=
> by SMTP, ldaps, HTTPS, HTTP/2.0, websockets, etc).
>
> Think of a simple HTTP-based server app receiving a HTTP/1.0 request > from a TLS-stack on top of a blocking network socket.=C2=A0 If the App= would
> keep calling SSL_read() (for an OpenSSL-style API), it would get stuck=
> (blocked on read), and at some point the client would give up and
> close the connection (with close_notify or TCP RST), and the server > waking from either the processing of the close_notify or the TCP RST > would be unable to deliver a response (which the client would not read=
> anyway).

This is an example of the application not knowing which chan= nels are ready. So no the app doesn't "know when to read".

>
> Whether or not the calling App wants to shutdown a communication
> at different times in both directions depends on the existing semantic= s
> of that application (which has just added TLS protection around its > communication).=C2=A0 Reading and processing a close_notify in the TLS= stack
> (e.g. OpenSSL) will tear down *BOTH* directions immediately, and precl= ude
> any further of sending of responses by the application, so the middlew= are
> really will want to hold of processing of close_notify alerts unless > _explicitly_ asked to read further AppData by the application.
>
> With TLS up to TLSv1.2 streaming is no problem, the middleware can
> easily recognize non-AppData records and avoid passing them to
> the TLS stack for processing unless the application explicitly asks > the middleware to do so.=C2=A0 When TLSv1.3 hides the ContentType,
> the fact that a close_notify was received & processed can only be<= br> > determined after the fact, when the shattered pieces are on the floor.=
> Communication in the other direction will be impossible, and it will > not be possible to prevent this from happening.
>
> While it is conceivable to jump hoops and implement new APIs and
> callback for the TLS stack to allow the middleware instrumenting
> and holding off the processing of TLS close_notify, this is not
> going to allow a drop-in replacement of an existing TLSv1.2 with
> a ContentType-hiding TLSv1.3 implementation underneath an existing
> application.

Yes, you will need to update the middleware component as wel= l. Why is this a problem?

>
> For SSLv3->TLSv1.2, there was *NO* such backwards-incompatibilty. > We were able just fine to drop-in a TLSv1.2 implementation underneath<= br> > apps that were originally built on top of an SSLv3-only stack.
>
>
>
> >
> > Can you explain further why this is a problem: are you expecting = that
> > if you send application data to the client after sending the clos= e_notify
> > itself, the client will consume it?
> >
> > Can you help me understand?
>
> TCP is a full-duplex communication channel and allows shutdown for eac= h
> of the two communication directions performed independently.=C2=A0 The= re are
> existing communication protocols (other than HTTP) that _use_ independ= ent
> shutdown, and may want to continue using it even after starting to
> protect their original cleatext communication with TLS.
>
>
> If you're vaguely familiar with OpenSSL:
> when SSL_read() has received and processed a TLS record with a close_n= otify
> alert, do you know what happens to further calls of SSL_write() of the= same
> handle, which technically is _the_other_ communication direction.

Is this the case? Actually alerts trigger teardown of both s= ides. There is no half open state for TLS. Nginx manages fine on OpenSSL. <= /p>

>
> If you don't know: SSL_write() will fail, because OpenSSL will pus= h out
> a close_notify alert from within SSL_read(), and make the connection > unusable.=C2=A0 Being able to distinguish AppData records from non-App= Data
> records, an application caller of SSL_read() (such as my middleware) > can prevent loosing the backchannel with no prior warning -- if it
> wants to.=C2=A0 For streaming operation, my middleware DESPERATELY wan= ts to
> prevent the communication channel becoming unusable in both directions=
> _before_ the application has received/seen all the app data from the c= hannel.
>
>
> -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a1140fd58d7ba250540e57c8c-- From nobody Thu Nov 10 08:22:23 2016 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 CED0E1298B5 for ; Thu, 10 Nov 2016 08:22:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 dlmGTcsp7Rd6 for ; Thu, 10 Nov 2016 08:22:20 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id D0E811298BC for ; Thu, 10 Nov 2016 08:22:19 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C11D2423726; Thu, 10 Nov 2016 16:22:18 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id A0647423711; Thu, 10 Nov 2016 16:22:18 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478794938; bh=tn+EE0+IK89rpZ0kZwoOI8r7eiTC9TGZuRWbZk4iVi0=; l=2598; h=To:References:Cc:From:Date:In-Reply-To:From; b=OTt9IDLof9APgSyn9COjXtSqEC95yNX/8SgMWxhlRjaxNGs33TJcvHeUggQHf0pR4 M3XYQoBwClW5K/i80OpM1LZ1adeXJvCwc4je/wRQokduTwuW9qVSx/eN4eQQu38M8P RNW5Lzj5hoQGAbmP7n/H+9atzI9QRKiSSYe5XESk= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 34FC61FC93; Thu, 10 Nov 2016 16:22:18 +0000 (GMT) To: Martin Thomson , Brian Smith References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> From: Benjamin Kaduk Message-ID: <79f10997-3bbc-fbce-91ae-2ceecaaa653e@akamai.com> Date: Thu, 10 Nov 2016 10:22:17 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BE8B1D1448232E117B78107D" Archived-At: Cc: Matt Caswell , "tls@ietf.org" Subject: Re: [TLS] (strict) decoding of legacy_record_version? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Nov 2016 16:22:22 -0000 This is a multi-part message in MIME format. --------------BE8B1D1448232E117B78107D Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 11/08/2016 06:25 PM, Martin Thomson wrote: > On 9 November 2016 at 05:59, Brian Smith wrote: >> This isn't a pervasively shared goal, though. It's good to let the browsers >> police things if they want, but I think a lot of implementations would >> prefer to avoid doing work that isn't necessary for interop or security. > If you permit someone to enforce it, then that is sufficient. I don't > think that we should ever force someone to enforce these sorts of > things (as you say, sometimes strict enforcement isn't cheap or even > desirable). > Agreed. We should probably change the text a bit, though, as right now readers can get two different readings depending on whether they go for a strict decode_error (or illegal_parameter?) since the struct doesn't match the definition, or follow the "MUST be ignored for all purposes". -Ben --------------BE8B1D1448232E117B78107D Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 11/08/2016 06:25 PM, Martin Thomson wrote:
On 9 November 2016 at 05:59, Brian Smith <brian@briansmith.org> wrote:

This isn't a pervasively shared goal, though. It's good to let the browsers
police things if they want, but I think a lot of implementations would
prefer to avoid doing work that isn't necessary for interop or security.

If you permit someone to enforce it, then that is sufficient.  I don't
think that we should ever force someone to enforce these sorts of
things (as you say, sometimes strict enforcement isn't cheap or even
desirable).

Agreed.  We should probably change the text a bit, though, as right now readers can get two different readings depending on whether they go for a strict decode_error (or illegal_parameter?) since the struct doesn't match the definition, or follow the "MUST be ignored for all purposes".

-Ben
--------------BE8B1D1448232E117B78107D-- From nobody Thu Nov 10 09:02:28 2016 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 C556812943B for ; Thu, 10 Nov 2016 09:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 rySS3Kgkaopa for ; Thu, 10 Nov 2016 09:02:24 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E42021293E8 for ; Thu, 10 Nov 2016 09:02:23 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C2361433450; Thu, 10 Nov 2016 17:02:22 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AB2EE433402; Thu, 10 Nov 2016 17:02:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478797342; bh=EAB8pIMiYP9Tju8QipbdMUD1jQg6eBJIMqctteYSgFM=; l=3061; h=To:References:Cc:From:Date:In-Reply-To:From; b=c/qekjfnJHI/9IsfRnVJvbZpHYCLzvwCwSoGw8XEwqnjfXpw9n9PKJkolg/3qYH80 eg0joEVoct127WFSNoP/OyfD3yBr8goiLSrbaIiEoorv6U512HJ8ZiKHDQEt+oxgQV l0QtM9Sf/eEzssJQjfKIs4lU5JlWL5kefv/PsdTE= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 603171FC90; Thu, 10 Nov 2016 17:02:22 +0000 (GMT) To: mrex@sap.com, Eric Rescorla References: <20161109194210.8ED431A579@ld9781.wdf.sap.corp> From: Benjamin Kaduk Message-ID: <2780eb54-6b37-fd30-49d4-c4ebf29177e5@akamai.com> Date: Thu, 10 Nov 2016 11:02:22 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161109194210.8ED431A579@ld9781.wdf.sap.corp> Content-Type: multipart/alternative; boundary="------------9FDCEA331F140DA0B1924363" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Nov 2016 17:02:26 -0000 This is a multi-part message in MIME format. --------------9FDCEA331F140DA0B1924363 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 11/09/2016 01:42 PM, Martin Rex wrote: > Whether or not the calling App wants to shutdown a communication > at different times in both directions depends on the existing semantics > of that application (which has just added TLS protection around its > communication). Reading and processing a close_notify in the TLS stack > (e.g. OpenSSL) will tear down *BOTH* directions immediately, and preclude > any further of sending of responses by the application, so the middleware > really will want to hold of processing of close_notify alerts unless > _explicitly_ asked to read further AppData by the application. I don't understand. As Watson notes, TLS does not have a half-closed state. So, if the application wants to continue receiving data, the application protocol should not [inform the TLS stack to] generate a close_notify until the entire application-layer protocol is done, in both directions. Maybe that would work on plain TCP (no TLS), but I just don't see how this should be expected to always work with TCP+TLS between endpoints using different implementations. -Ben --------------9FDCEA331F140DA0B1924363 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 11/09/2016 01:42 PM, Martin Rex wrote:
Whether or not the calling App wants to shutdown a communication
at different times in both directions depends on the existing semantics
of that application (which has just added TLS protection around its
communication).  Reading and processing a close_notify in the TLS stack
(e.g. OpenSSL) will tear down *BOTH* directions immediately, and preclude
any further of sending of responses by the application, so the middleware
really will want to hold of processing of close_notify alerts unless
_explicitly_ asked to read further AppData by the application.

I don't understand.  As Watson notes, TLS does not have a half-closed state.
So, if the application wants to continue receiving data, the application protocol should not [inform the TLS stack to] generate a close_notify until the entire application-layer protocol is done, in both directions.  Maybe that would work on plain TCP (no TLS), but I just don't see how this should be expected to always work with TCP+TLS between endpoints using different implementations.

-Ben
--------------9FDCEA331F140DA0B1924363-- From nobody Thu Nov 10 09:02:46 2016 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 70FF51293E8 for ; Thu, 10 Nov 2016 09:02:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 m2jS4GwpsgjY for ; Thu, 10 Nov 2016 09:02:42 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2605C12943B for ; Thu, 10 Nov 2016 09:02:42 -0800 (PST) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3tF8Vm1LpMz1HZ2; Thu, 10 Nov 2016 18:02:40 +0100 (CET) X-purgate-ID: 152705::1478797360-00003836-72968354/0/0 X-purgate-size: 2051 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3tF8Vk3FrbzGny7; Thu, 10 Nov 2016 18:02:38 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6A4D91A57D; Thu, 10 Nov 2016 18:02:38 +0100 (CET) In-Reply-To: To: Watson Ladd Date: Thu, 10 Nov 2016 18:02:38 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161110170238.6A4D91A57D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Thu, 10 Nov 2016 17:02:44 -0000 I'm sorry for the confusion. It seems I was wrong about OpenSSL behaviour. Watson Ladd wrote: > Martin Rex wrote: >> >> If you're vaguely familiar with OpenSSL: >> when SSL_read() has received and processed a TLS record with a >> close_notify alert, do you know what happens to further calls >> of SSL_write() of the same handle, which technically is >> _the_other_ communication direction. > > Is this the case? Actually -- no, I'm sorry. I looked at the OpenSSL code again, and it doesn't seem to do that on receipt of CLOSE_NOTIFY. (It's more than 10 years that I programmed on top of OpenSSL). CLOSE_NOTIFY seems to only be sent after an explict call of SSL_shutdown(), and connection state (for the other direction) does not seem to be harmed by receipt CLOSE_NOTIFY, nor by sending of CLOSE_NOTIFY (warning-level) alerts. Only the communication direction that carried CLOSE_NOTIFY seems (properly) defunct (ignoring further IO requests). It seems that I was mislead by the semantics described in the TLS specification. > > Actually alerts trigger teardown of both sides. There is > no half open state for TLS. Nginx manages fine on OpenSSL. Teardown of both sides applies to fatal Alerts only. One of the reason for warning level alerts is that they should not tear down the connection state, and close_notify (although the semantics described in rfc5246 suggest otherwise) should tear down only the direction on which it was sent. So essentially, TLS should allow half-closed state, and at least a glance over the OpenSSL code suggests that this implementation would support it. >From the sequence of (data processing) events, I still want to hold off processing of CloseNotify until all prior TLS AppData records are properly consumed by the application caller, so that when the code writes traces about the progress of processing a connection, the processing of the Alert will follow the passing of all prior AppData to the application, and never precede it. -Martin From nobody Thu Nov 10 09:06:09 2016 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 EC12012947E for ; Thu, 10 Nov 2016 09:06:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.217 X-Spam-Level: X-Spam-Status: No, score=-4.217 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 S3lmhz5GaCyh for ; Thu, 10 Nov 2016 09:06:06 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9A112941A for ; Thu, 10 Nov 2016 09:06:06 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C1B1F423712; Thu, 10 Nov 2016 17:06:05 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id AB640423701; Thu, 10 Nov 2016 17:06:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478797565; bh=3CSByD2IhJnHNfIXI24h0RpR1uHBxazEB/E61ZgaHxA=; l=3125; h=To:References:Cc:From:Date:In-Reply-To:From; b=fWSVXnKMz4QnnR/k6VpvjeC82Znghht1OB0vrXfXPavGcVv3zu/Td1L0Dbq+NZ6OZ oQECj5eMRAC493CIsbEE223tCBqWJSMat42PPczX98/VhYq3S6ONMUk2QGrgbytU9K aJIqTH23dexfO5zQriMKBB9N9zbgAdilJGaksEAM= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 647AA1FCA1; Thu, 10 Nov 2016 17:06:05 +0000 (GMT) To: mrex@sap.com, Daniel Kahn Gillmor References: <20161109174219.454D21A579@ld9781.wdf.sap.corp> From: Benjamin Kaduk Message-ID: <58fd43a5-fd20-b93c-fae0-845646a8062f@akamai.com> Date: Thu, 10 Nov 2016 11:06:05 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161109174219.454D21A579@ld9781.wdf.sap.corp> Content-Type: multipart/alternative; boundary="------------D464E2AE7A35E94FB5582FA3" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Nov 2016 17:06:08 -0000 This is a multi-part message in MIME format. --------------D464E2AE7A35E94FB5582FA3 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 11/09/2016 11:42 AM, Martin Rex wrote: > Nobody so far has provide a single example of *REAL* value. > For the hiding of ContentType to provide real value, the prerequisites are: > > (1) this value will be _unconditionally_ provided in TLSv1.3 > > (2) this value can be demonstrated to be a real security issue in TLSv1.2, > for existing usage scenarios, where hiding of ContentType is not > available > > Anyhing less is no value, just an illusion of value. Thanks for clarifying your position. I don't think many of the other people in the thread are using the same definition of "value", which has led to a lot of confusion. However, I'm not convinced that the concrete benefit needs to be mandatory-to-use in TLS 1.3 to be considered to provide value. For example, I personally value having the option to have my car's air conditioning unit cool the interior temperature, but I wouldn't want it to be the only way to cool the interior -- the rush of wind through the windows is a different experience. That is, having an option can in itself provide value to some people in some situations. -Ben --------------D464E2AE7A35E94FB5582FA3 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 11/09/2016 11:42 AM, Martin Rex wrote:
Nobody so far has provide a single example of *REAL* value.
For the hiding of ContentType to provide real value, the prerequisites are:

  (1) this value will be _unconditionally_ provided in TLSv1.3

  (2) this value can be demonstrated to be a real security issue in TLSv1.2,
      for existing usage scenarios, where hiding of ContentType is not
      available

Anyhing less is no value, just an illusion of value.

Thanks for clarifying your position.  I don't think many of the other people in the thread are using the same definition of "value", which has led to a lot of confusion.

However, I'm not convinced that the concrete benefit needs to be mandatory-to-use in TLS 1.3 to be considered to provide value.  For example, I personally value having the option to have my car's air conditioning unit cool the interior temperature, but I wouldn't want it to be the only way to cool the interior -- the rush of wind through the windows is a different experience.  That is, having an option can in itself provide value to some people in some situations.

-Ben
--------------D464E2AE7A35E94FB5582FA3-- From nobody Thu Nov 10 09:13:57 2016 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 94223129410 for ; Thu, 10 Nov 2016 09:13:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 oIEWJ624nncx for ; Thu, 10 Nov 2016 09:13:55 -0800 (PST) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3230A1293F0 for ; Thu, 10 Nov 2016 09:13:55 -0800 (PST) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3tF8lj5JlDz25Nk; Thu, 10 Nov 2016 18:13:53 +0100 (CET) X-purgate-ID: 152705::1478798033-00003836-432DB077/0/0 X-purgate-size: 1468 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3tF8lj1ycbzGnyV; Thu, 10 Nov 2016 18:13:53 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 37D451A57D; Thu, 10 Nov 2016 18:13:53 +0100 (CET) In-Reply-To: <58fd43a5-fd20-b93c-fae0-845646a8062f@akamai.com> To: Benjamin Kaduk Date: Thu, 10 Nov 2016 18:13:53 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161110171353.37D451A57D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Thu, 10 Nov 2016 17:13:56 -0000 Benjamin Kaduk wrote: [ Charset windows-1252 unsupported, converting... ] > On 11/09/2016 11:42 AM, Martin Rex wrote: > > Nobody so far has provide a single example of *REAL* value. > > For the hiding of ContentType to provide real value, the prerequisites are: > > > > (1) this value will be _unconditionally_ provided in TLSv1.3 > > > > (2) this value can be demonstrated to be a real security issue in TLSv1.2, > > for existing usage scenarios, where hiding of ContentType is not > > available > > > > Anyhing less is no value, just an illusion of value. > > Thanks for clarifying your position. I don't think many of the other > people in the thread are using the same definition of "value", which has > led to a lot of confusion. > > However, I'm not convinced that the concrete benefit needs to be > mandatory-to-use in TLS 1.3 to be considered to provide value. There is a concept called "provable correctness", and folks (such as those from the miTLS implementation) are using this approach to check/prove whether TLS provides certain security properties (rather than just assuming that these properties are provided). If hiding of ContentType has *real* value, then this property will be formally provable. If the properties that someone asserts as value can be proven to not exist (one counterexample is sufficient), then the value is an illusion / obscurity, and definitely not real value. -Martin From nobody Thu Nov 10 09:16:29 2016 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 2CE14129434 for ; Thu, 10 Nov 2016 09:16:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 MKLgNb7IBm5d for ; Thu, 10 Nov 2016 09:16:26 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id E18D9129410 for ; Thu, 10 Nov 2016 09:16:25 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 403C743347D; Thu, 10 Nov 2016 17:16:25 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 2487B43340F; Thu, 10 Nov 2016 17:16:25 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478798185; bh=q+rbfuL3QxNtecOiatE1DtGXjbu93Dg+g/BlN0l1adQ=; l=2499; h=To:References:Cc:From:Date:In-Reply-To:From; b=Ok76EFytLfjBFi3ZtdDujgZSd73kRIkPW+vxLUQ/h/j669nR6pN5ED0+XSoK9ny1A u1duOnFbHn99zj4UEG9Roa+Kgx4zmtw3bN95LvK1W2udY3OuBdTCZ+T3rJzw/jstCV mdyZmeQW7CPy5AkwI2vHaqAV2+PiJCMMahDRA/gk= Received: from [172.19.0.25] (bos-lpczi.kendall.corp.akamai.com [172.19.0.25]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id D4AD71FC93; Thu, 10 Nov 2016 17:16:24 +0000 (GMT) To: mrex@sap.com References: <20161110171353.37D451A57D@ld9781.wdf.sap.corp> From: Benjamin Kaduk Message-ID: <4d10cc42-6a44-5c97-a246-56c31ac7fef1@akamai.com> Date: Thu, 10 Nov 2016 11:16:24 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161110171353.37D451A57D@ld9781.wdf.sap.corp> Content-Type: multipart/alternative; boundary="------------1FEFC25E29C36D6048A59B0C" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Nov 2016 17:16:27 -0000 This is a multi-part message in MIME format. --------------1FEFC25E29C36D6048A59B0C Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 11/10/2016 11:13 AM, Martin Rex wrote: > > There is a concept called "provable correctness", and folks (such as > those from the miTLS implementation) are using this approach to check/prove > whether TLS provides certain security properties (rather than just > assuming that these properties are provided). > > If hiding of ContentType has *real* value, then this property will be > formally provable. If the properties that someone asserts as value > can be proven to not exist (one counterexample is sufficient), > then the value is an illusion / obscurity, and definitely not real value. > > My understanding was that our current knowledge of what capabilities traffic analysis makes possible and the countermeasures against them is quite poor, certainly not to the level where rigorous proofs are possible. So, I fear we must be operating "in the dark" in this regard for the near future. -Ben --------------1FEFC25E29C36D6048A59B0C Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 11/10/2016 11:13 AM, Martin Rex wrote:

There is a concept called "provable correctness", and folks (such as
those from the miTLS implementation) are using this approach to check/prove
whether TLS provides certain security properties (rather than just
assuming that these properties are provided).

If hiding of ContentType has *real* value, then this property will be
formally provable.  If the properties that someone asserts as value
can be proven to not exist (one counterexample is sufficient),
then the value is an illusion / obscurity, and definitely not real value.


My understanding was that our current knowledge of what capabilities traffic analysis makes possible and the countermeasures against them is quite poor, certainly not to the level where rigorous proofs are possible.  So, I fear we must be operating "in the dark" in this regard for the near future.

-Ben
--------------1FEFC25E29C36D6048A59B0C-- From nobody Thu Nov 10 09:26:42 2016 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 AA7C6129455 for ; Thu, 10 Nov 2016 09:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 6eplKEZSJIVK for ; Thu, 10 Nov 2016 09:26:40 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 826E912943B for ; Thu, 10 Nov 2016 09:26:40 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 1817E423701; Thu, 10 Nov 2016 17:26:40 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id D49DE42372B; Thu, 10 Nov 2016 17:26:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1478798799; bh=+d+jGNepjPp77DGwZhQmKRNBBdd8CpxkaLtucb7omlA=; l=237; h=From:To:CC:Date:References:In-Reply-To:From; b=hynTHFUWhZ8FtNvtljJYHt6p/BHTWKTlF+3iq8qpe5PCfJPMIgAd+CLPCPdG3SHOw ZG9Rp5VpJS6pNelChYSoDtRRby9JC3PKIMt+NyvEBDU3KkXSGtrJlw0sldkovdoAvr uxNSkOf5tKS38htz3b/j5Cw/JQwxjtU+JBq/Fp3o= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id CEC981FCA1; Thu, 10 Nov 2016 17:26:39 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 10 Nov 2016 12:26:39 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Thu, 10 Nov 2016 12:26:39 -0500 From: "Salz, Rich" To: "mrex@sap.com" , "Kaduk, Ben" Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 Thread-Index: AQHSL/2+7HM9ClSQ40Wwf3PQxwdBMaC+S8KAgAAG0ACAACSwgIABS5EAgAfeKgCAADJLgIAADcgAgAAE9wCAB7aeAP//2qmAgAFUmQCAAH7egIAACk2AgAGINYCAAAIugP//r4eA Date: Thu, 10 Nov 2016 17:26:39 +0000 Message-ID: References: <58fd43a5-fd20-b93c-fae0-845646a8062f@akamai.com> <20161110171353.37D451A57D@ld9781.wdf.sap.corp> In-Reply-To: <20161110171353.37D451A57D@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.44.61] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 10 Nov 2016 17:26:42 -0000 > There is a concept called "provable correctness", and folks (such as thos= e Hm, your arguments against it are that heuristics will expose the informati= on anyway. Has provability advanced far enough to include that concept? From nobody Thu Nov 10 09:31:02 2016 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 4197E12948B for ; Thu, 10 Nov 2016 09:31:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RQD4Ap1xm05q for ; Thu, 10 Nov 2016 09:30:58 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548D312947E for ; Thu, 10 Nov 2016 09:30:58 -0800 (PST) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3tF97N6YM3z1J35; Thu, 10 Nov 2016 18:30:56 +0100 (CET) X-purgate-ID: 152705::1478799056-0000521C-AC3B6C46/0/0 X-purgate-size: 2293 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3tF97M57tRzGny8; Thu, 10 Nov 2016 18:30:55 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A50691A57D; Thu, 10 Nov 2016 18:30:55 +0100 (CET) In-Reply-To: <4d10cc42-6a44-5c97-a246-56c31ac7fef1@akamai.com> To: Benjamin Kaduk Date: Thu, 10 Nov 2016 18:30:55 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161110173055.A50691A57D@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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: Thu, 10 Nov 2016 17:31:00 -0000 Benjamin Kaduk wrote: [ Charset windows-1252 unsupported, converting... ] > On 11/10/2016 11:13 AM, Martin Rex wrote: > > > > There is a concept called "provable correctness", and folks (such as > > those from the miTLS implementation) are using this approach to check/prove > > whether TLS provides certain security properties (rather than just > > assuming that these properties are provided). > > > > If hiding of ContentType has *real* value, then this property will be > > formally provable. If the properties that someone asserts as value > > can be proven to not exist (one counterexample is sufficient), > > then the value is an illusion / obscurity, and definitely not real value. > > My understanding was that our current knowledge of what capabilities > traffic analysis makes possible and the countermeasures against them is > quite poor, certainly not to the level where rigorous proofs are > possible. So, I fear we must be operating "in the dark" in this regard > for the near future. Proving that something is secure can be pretty difficult, that is correct. Proving that something is insecure can be pretty trivial (one counterexample is sufficient). For someone who does this formal proofing stuff regularly, it may already be possible today to formally proof that hiding the ContentType can not possibly provide any value. Where is the value with hiding the ContentType of SSL Alerts? We know that at least one implementations notoriously _not_ sends any alerts before closing connnections. The installed base has somehow managed to live with it. But it's often painful to figure out the cause of handshake failures, and to distinguish a certain kind of server accept()ing and silently closing a connection after hitting a bug (or policy) from an overzealous firewall (NAT or "transparent internet proxy"). So if your implementation has anything to hide, performing a dirty socket closure (resulting in a TCP RST) will be *MUCH* more effective in hiding information from observers than hiding the TLS Alert ContentType. Silent connection closures are certainly much more effective for leaving rightful communication peers (&helpdesk &support) in the dark about why the heck communication is failing. -Martin From nobody Thu Nov 10 23:10:24 2016 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 11C98129A0D for ; Thu, 10 Nov 2016 23:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 2Sn0W25Xe2c0 for ; Thu, 10 Nov 2016 23:10:16 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A1D1129519 for ; Thu, 10 Nov 2016 23:10:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1478848215; x=1510384215; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ehxfls3zax88IO4E4x4SFcukwTnAiO81AuGzNkzoi8E=; b=QCHADdIrBFDB0i4+cROMgauvgASpoPmcDO0Hra91WA5fiWwc8UFMHDUD 7s5YpOl+Jjjairq8WauEo+baU/HR4Aiyw5aind42/scYWGaKRt391Z8/s h1dwkfeDKr3dNVosy69u+28eGcfY5OkEbLwQgCVnZZBfGKyuXWyPlcIJh RB0i4hMMRKamOnmHvKaCXc+htoGADRQ7L6sXPaLnllKOBiJWEgLD67fH9 +d22vtEhlBjnBfWsAgrfCVCMUmYMRSk3UHjhRaXiYgKMYv72tTs1A6LAH akv4kJ53I5KGZNfEyozdNGxyleQZTBjUayPxlISzBGg+nIWMWAssZXodn g==; X-IronPort-AV: E=Sophos;i="5.31,620,1473076800"; d="scan'208";a="114726594" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.3 - Outgoing - Outgoing Received: from uxcn13-ogg-b.uoa.auckland.ac.nz ([10.6.2.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 11 Nov 2016 20:10:10 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-b.UoA.auckland.ac.nz (10.6.2.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 11 Nov 2016 20:10:10 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 11 Nov 2016 20:10:10 +1300 From: Peter Gutmann To: Benjamin Kaduk , "mrex@sap.com" Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 Thread-Index: AQHSOdR09JVOl87da0itkD0J6z/Dh6DOi14AgAD/HACAAH7egIAACk2AgAGINYCAAAIugIABw0Qj Date: Fri, 11 Nov 2016 07:10:09 +0000 Message-ID: <1478848205508.80812@cs.auckland.ac.nz> References: <58fd43a5-fd20-b93c-fae0-845646a8062f@akamai.com>, <20161110171353.37D451A57D@ld9781.wdf.sap.corp> In-Reply-To: <20161110171353.37D451A57D@ld9781.wdf.sap.corp> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 11 Nov 2016 07:10:23 -0000 Martin Rex writes:=0A= =0A= >There is a concept called "provable correctness", =0A= =0A= The problem with provable whatever is that it merely proves that, as far as= =0A= the provers can tell, the thing they're dealing with conforms to some abstr= act=0A= model. I don't think you can prove much about whatever hiding the ContentT= ype=0A= is supposed to achieve because there's no model for it that says, for examp= le,=0A= "for an attacker with these capabilities, under these conditions, the=0A= following security guarantees are provided".=0A= =0A= However, we do have a pile of empirical data showing that pretty much any= =0A= seems-like-a-good-idea traffic-hiding really only works until the moment=0A= someone tries to attack it. The best reference for this is "Peek-a-Boo, I= =0A= Still See You: Why Efficient Traffic Analysis Countermeasures Fail" by Dyer= et=0A= al. So at the moment I'd say that if there's some measure that's completel= y=0A= free (no downsides for anything else) then you may as well apply it because= it=0A= can't make things any worse, but not to say "let's do X because it seems li= ke=0A= a good idea" when it has no empirically-demonstrable benefit but lots of=0A= drawbacks.=0A= =0A= And it's the "empirically-demonstrable" that's important, Peek-a-Boo is cho= ck=0A= full of examples of things that seemed like a good idea but that don't=0A= actually provide much, if any, benefit, while at the same time introducing = all=0A= sorts of downsides.=0A= =0A= Peter.= From nobody Fri Nov 11 17:37:41 2016 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 66F931297BD for ; Fri, 11 Nov 2016 17:37:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 IvPihhl3FUAj for ; Fri, 11 Nov 2016 17:37:38 -0800 (PST) Received: from BAY004-OMC1S27.hotmail.com (bay004-omc1s27.hotmail.com [65.54.190.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC77512007C for ; Fri, 11 Nov 2016 17:37:38 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.54.190.59]) by BAY004-OMC1S27.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 11 Nov 2016 17:37:38 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/T5FcEFAz9at4uL2pXEV0jQxzN2pOvhcLkI3Yg73jOU=; b=T42TszU3fcVNaZi6tL2NUEdHvSUdjZNwSn3RlvkRM/4rVCzcNcoNGKykdfE5MBnjT+cn1UMU1M1wivt9UIR6Ssoy6AGpLsP/yWYke+QIkX8gXq+CUx6N/gJ/z4H5CDNhpZki5mzk6deOBTGlquNjKmrZfLF2qTBdZaX5YnWvAxytzojGw+CvHYBhJ/RdxfZuLQEHDJuQjsjqI2QjI4KVkQ/eFROKyxcQjz1LoEmoZhW7nl/8sCCxHm1o6SnMOI1SNnv4bix84eXCuZu5gySCIp7KlygMKezLCsgO+W1LjYHTXWWvjDDkNEFOznagMKRSRByThEGPasqlNRUN+r09JA== Received: from SN1NAM02FT013.eop-nam02.prod.protection.outlook.com (10.152.72.52) by SN1NAM02HT159.eop-nam02.prod.protection.outlook.com (10.152.73.183) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.3; Sat, 12 Nov 2016 01:37:37 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.72.60) by SN1NAM02FT013.mail.protection.outlook.com (10.152.72.98) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.3 via Frontend Transport; Sat, 12 Nov 2016 01:37:37 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0707.013; Sat, 12 Nov 2016 01:37:37 +0000 From: Xiaoyin Liu To: "tls@ietf.org" Thread-Topic: What is the meaning of three dots Thread-Index: AQHSPIVZdHePasv4VkueoQmkT11ByQ== Date: Sat, 12 Nov 2016 01:37:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:7216; Count:37 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [3CtaSkhmHaGrApKTVMPiFWF8GAjk50HC] x-incomingheadercount: 37 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; SN1NAM02HT159; 7:ucjBI2lOytNO3OUoMdMBwZYxFgrfR0Zp4v84vLsd9Xhi6hqutoXFhIhkidsfnJB6c2nlw2BqZITduniQJr8j8FPxgw95mEA5fAe6k60CDgjWxrxD7ajFo4TY8R9Upp/zu6WNbWWLoa7aMwxviRocxzGYUsr8tD/b0wJrbNycV0hTAPnUi8tlxRhTme+nBIOncOEtEnH9hERg0qPmSeXhe+Dcwap6LIceE2SP7IxkgQn9wK+tAOtnx9pkepku21OFQyMUPVsqftv3ZIPMr7kZlgt/qm4YTm91hyTppWs9XygoL4zPcE6xKms+Ar7Nq/BDIP+uJCsKMccWDHPVJSiQmQkHhMAVxLIzt9pNidYfYmc= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT159; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 2268b362-c467-48a8-098e-08d40a9c7ba9 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(1603103113)(1601125047)(1603101340); SRVR:SN1NAM02HT159; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM02HT159; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT159; x-forefront-prvs: 01244308DF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB07784D3299B78C8C0D388735FFBA0CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2016 01:37:37.0753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT159 X-OriginalArrivalTime: 12 Nov 2016 01:37:38.0766 (UTC) FILETIME=[5A21FEE0:01D23C85] Archived-At: Subject: [TLS] What is the meaning of three dots X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 12 Nov 2016 01:37:40 -0000 --_000_CY1PR15MB07784D3299B78C8C0D388735FFBA0CY1PR15MB0778namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNCldoYXQgaXMgdGhlIG1lYW5pbmcgb2YgdGhyZWUgZG90cyAo4oCmKSBpbiDigJxDbGll bnRIZWxsb+KAplNlcnZlckhlbGxv4oCdIGFuZCDigJxDbGllbnRIZWxsb+KAplNlcnZlciBGaW5p c2hlZOKAnSwgaW4gc2VjdGlvbiA3LjEgS2V5IFNjaGVkdWxlPyBJdCBzZWVtcyB0aGlzIHN5bnRh eCBpcyBub3QgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Lg0KDQpbMV0gaHR0cHM6Ly90bHN3Zy5n aXRodWIuaW8vdGxzMTMtc3BlYy8jcmZjLnNlY3Rpb24uNy4xDQoNClRoYW5rIHlvdSENCg0KQmVz dCwNClhpYW95aW4NCg== --_000_CY1PR15MB07784D3299B78C8C0D388735FFBA0CY1PR15MB0778namp_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v bmx5O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46 MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRT ZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiPg0KPGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2hhdCBpcyB0aGUgbWVhbmluZyBvZiB0aHJlZSBkb3RzICjigKYpIGluIOKAnENsaWVu dEhlbGxv4oCmU2VydmVySGVsbG/igJ0gYW5kIOKAnENsaWVudEhlbGxv4oCmU2VydmVyIEZpbmlz aGVk4oCdLCBpbiBzZWN0aW9uIDcuMSBLZXkgU2NoZWR1bGU/IEl0IHNlZW1zIHRoaXMgc3ludGF4 IGlzIG5vdCBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQuPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5bMV0gaHR0cHM6 Ly90bHN3Zy5naXRodWIuaW8vdGxzMTMtc3BlYy8jcmZjLnNlY3Rpb24uNy4xPC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5UaGFuayB5b3UhPC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0LDwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PlhpYW95aW48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_CY1PR15MB07784D3299B78C8C0D388735FFBA0CY1PR15MB0778namp_-- From nobody Fri Nov 11 17:40:53 2016 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 E34CF12947A for ; Fri, 11 Nov 2016 17:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 2MtC5oZ9KLLH for ; Fri, 11 Nov 2016 17:40:50 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 38BBB1293DC for ; Fri, 11 Nov 2016 17:40:50 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id t125so28895955ywc.1 for ; Fri, 11 Nov 2016 17:40:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vokbf09/wxnesuF5gSnN+HqapfG84vvSjP8+bEQH/WA=; b=lP9XyWBCdJm51lt73V6WXkTeMu//SrNi6H5ac1Xf5b8hH/wmE7C/G2g8wdvnXelI1g Nlr8HLkJ7pMcugmjU7D5SMjkhQq+EWIZTttt+oeoBfKji9ewr2kHwvfxoWIJ14qrfkcH uZQf3b6cceFA305ppMZpnkrenl/ruSvDOrSCJ82g3yrtU050dJQPB+nqpSy8kf7aHzVK aBpWNJUxSV10fTcB4lQ9Nb5wFDEJvW+8lNU7jQ8KfCeWKdPuNMXHv0O0b/FO7zwtKhFt MxCfQ+EgbJpZNycgEYQD7P80eTT+k3fYKbzMhNCQMrUZcwq6ZOqMFcJUyBN0OJxuna0p sakg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vokbf09/wxnesuF5gSnN+HqapfG84vvSjP8+bEQH/WA=; b=WBOjjrVUKZYTEZQWN8ncHjTFmkgnAJ73Uj8FH+JegMAzCxOo2yyuOLKEWpO1X9wnKy e7b9kuYi9GC/lN5xwZv5YDzWGn1cCJ0Ie/ecZuJDANtpd0iEwHl3++E0Pxw6hQmn7gFH H19+Qu/HXsGupumyQxiyaOEorASAp3KvbtClqZY5lJmOjD1lCu61TMRmdjStHPzyPD1N oNdqM3YyWYB9UfAjijB+u3alBOXlDPABupxCeks6bymi7+jEZrQT77JyLVk/+GO0V6Wd 1nFiP2CzrwqwgYQ2nZEd0zEH5uQV9jAWi230sIuKHySSrEUj/gOKv6VsYC3LVui+05qy daYQ== X-Gm-Message-State: ABUngvdOzwwcOTxsPFhRvkP+PNXX833oT/zU6U7ZNMiwY1qlqzPiAWMcCOF9Reo2WrLguCdoB6q7nP6euBoUew== X-Received: by 10.129.78.71 with SMTP id c68mr5655249ywb.21.1478914849496; Fri, 11 Nov 2016 17:40:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Fri, 11 Nov 2016 17:40:09 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 11 Nov 2016 17:40:09 -0800 Message-ID: To: Xiaoyin Liu Content-Type: multipart/alternative; boundary=001a114dac9c4221aa054110b240 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What is the meaning of three dots X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 12 Nov 2016 01:40:52 -0000 --001a114dac9c4221aa054110b240 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It means "all the messages in between". -Ekr On Fri, Nov 11, 2016 at 5:37 PM, Xiaoyin Liu wrote: > Hi, > > > > What is the meaning of three dots (=E2=80=A6) in =E2=80=9CClientHello=E2= =80=A6ServerHello=E2=80=9D and > =E2=80=9CClientHello=E2=80=A6Server Finished=E2=80=9D, in section 7.1 Key= Schedule? It seems this > syntax is not defined in this document. > > > > [1] https://tlswg.github.io/tls13-spec/#rfc.section.7.1 > > > > Thank you! > > > > Best, > > Xiaoyin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114dac9c4221aa054110b240 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It means "all the messages in between".

=
-Ekr


On Fri, Nov 11, 2016 at 5:37 PM, Xiaoyin Liu <xiaoyin.l@outlook.com> wrote:

Hi,

=C2=A0

What is the meaning of three dots (=E2=80=A6) in =E2= =80=9CClientHello=E2=80=A6ServerHello=E2=80=9D and =E2=80=9CClientHello=E2= =80=A6Server Finished=E2=80=9D, in section 7.1 Key Schedule? It seems this = syntax is not defined in this document.

=C2=A0

[1] https://tlswg.github.io/tls13-spec/#= rfc.section.7.1

=C2=A0

Thank you!

=C2=A0

Best,

Xiaoyin


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a114dac9c4221aa054110b240-- From nobody Fri Nov 11 18:04:41 2016 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 1E8B0129594 for ; Fri, 11 Nov 2016 18:04:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.718 X-Spam-Level: X-Spam-Status: No, score=-2.718 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 r8Sei9sd2Skv for ; Fri, 11 Nov 2016 18:04:37 -0800 (PST) Received: from BAY004-OMC2S12.hotmail.com (bay004-omc2s12.hotmail.com [65.54.190.87]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA5B7129487 for ; Fri, 11 Nov 2016 18:04:37 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.54.190.125]) by BAY004-OMC2S12.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Fri, 11 Nov 2016 18:04:37 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=3lbRiAIsvXPGZyn2DVzbXJieZCeyM7wKVMfG5/5EBAc=; b=Tp3LfU/OK9z+HmqAND51sCGqy+OLv5VlHQbAPPl2HQaH+uPO/3HF7saAwqG74p/xtji8Oc0ZIh9NshiCU6BRHbqIuh7n35Ve/YoqRnSpRDPIhSpWFTqBLrIvyAS5TWBkBBIQA4y76uPB+wzhkRVYub3Yu5LJ4f2C5R6oQ3/6gkPwC/WfPtIYk99aWTnOqltib6VtHN2aRaEFUKjytJzWEunBRjLHxjPkMZqvVgejh7wki34cgbMvexxz/dTei8wqFEnze9mLGHao3ETY3KCl2IcW7H94rKSQtE8nVWoED9vO08u0ZczV1jOVJ5vL9Dqj6GmHuzDGSMr6+QjM7YPiCw== Received: from BL2NAM02FT010.eop-nam02.prod.protection.outlook.com (10.152.76.57) by BL2NAM02HT234.eop-nam02.prod.protection.outlook.com (10.152.77.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.3; Sat, 12 Nov 2016 02:04:36 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com (10.152.76.52) by BL2NAM02FT010.mail.protection.outlook.com (10.152.77.53) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.707.3 via Frontend Transport; Sat, 12 Nov 2016 02:04:35 +0000 Received: from CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) by CY1PR15MB0778.namprd15.prod.outlook.com ([10.169.22.10]) with mapi id 15.01.0707.013; Sat, 12 Nov 2016 02:04:35 +0000 From: Xiaoyin Liu To: Eric Rescorla Thread-Topic: [TLS] What is the meaning of three dots Thread-Index: AQHSPIVZdHePasv4VkueoQmkT11ByaDUklyAgAAG078= Date: Sat, 12 Nov 2016 02:04:35 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: rtfm.com; dkim=none (message not signed) header.d=none;rtfm.com; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:7525; Count:40 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [pic6lXbAi2vvblu9c1aH9hM32nkUroyU] x-incomingheadercount: 40 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; BL2NAM02HT234; 7:UozKdDstPqSPh5jBeINWRjWUGBws0r41l3uTYYb0AMdNVzOiWmmPnCLdShZmiNVY2fZipg49lHbrr9uUi6lbHN4H2RjhArr6lK4BNGFZcLpuV1bNrAvQAKbKKkckpDcA0gobNmMX9zLRKfVAB9WPIuVUEbd3PAXdKarvx1EXvn/CSeKnPjtR/iviLbbfyBzYP196ox9AsViFlaTyVHMiVlVJ58wRqGrLYEEkiMow90S4ISsvxswo3RQ/6GmnSLjo7LBfV1NZiglkyWJ18aqTZgAuf8t48PokNwHNFXvOeGTM3p6afrsZzCslI0RGConOg8FOKdUbehhziO5qyVZCSnwVREPguZc7dDvyNoOZfRo= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2NAM02HT234; H:CY1PR15MB0778.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: a9c54472-ab22-4bbd-06f2-08d40aa04072 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(1603103113)(1601125047)(1603101340); SRVR:BL2NAM02HT234; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:BL2NAM02HT234; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT234; x-forefront-prvs: 01244308DF spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY1PR15MB0778F09BFCC44EECB6D22009FFBA0CY1PR15MB0778namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Nov 2016 02:04:35.7251 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT234 X-OriginalArrivalTime: 12 Nov 2016 02:04:37.0535 (UTC) FILETIME=[1EFE8AF0:01D23C89] Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] What is the meaning of three dots X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 12 Nov 2016 02:04:40 -0000 --_000_CY1PR15MB0778F09BFCC44EECB6D22009FFBA0CY1PR15MB0778namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I see. Thank you, Eric! Xiaoyin From: Eric Rescorla Sent: Friday, November 11, 2016 8:49 PM To: Xiaoyin Liu Cc: tls@ietf.org Subject: Re: [TLS] What is the meaning of three dots It means "all the messages in between". -Ekr On Fri, Nov 11, 2016 at 5:37 PM, Xiaoyin Liu > wrote: Hi, What is the meaning of three dots (...) in "ClientHello...ServerHello" and = "ClientHello...Server Finished", in section 7.1 Key Schedule? It seems this= syntax is not defined in this document. [1] https://tlswg.github.io/tls13-spec/#rfc.section.7.1 Thank you! Best, Xiaoyin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_CY1PR15MB0778F09BFCC44EECB6D22009FFBA0CY1PR15MB0778namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I see. Thank you, Eric!

 

Xiaoyin

 

From: Eric Rescorla
Sent: Friday, November 11, 2016 8:49 PM
To: Xiaoyin Liu
Cc: tls@ietf.org
Subject: Re: [TLS] What is the meaning of three dots

 

It means "all the messages in between".

-Ekr


On Fri, Nov 11, 2016 at 5:37 PM, Xiaoyin Liu <xiaoyin.l@ou= tlook.com> wrote:

Hi,

 

What is the meaning of three dots (…) in ̶= 0;ClientHello…ServerHello” and “ClientHello…Server = Finished”, in section 7.1 Key Schedule? It seems this syntax is not d= efined in this document.

 

[1] https://tlswg.github.io/tls13-spec/#rfc.section.7.1

 

Thank you!

 

Best,

Xiaoyin


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--_000_CY1PR15MB0778F09BFCC44EECB6D22009FFBA0CY1PR15MB0778namp_-- From nobody Sun Nov 13 12:48:44 2016 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 CBD9F1294E2; Sun, 13 Nov 2016 12:48:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 s7le50TVBkkN; Sun, 13 Nov 2016 12:48:34 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0095.outbound.protection.outlook.com [23.103.200.95]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA87F12948C; Sun, 13 Nov 2016 12:48:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=irrD92n09SFOUJgESsjYqQfKFxPslF99y57dBTw0jrM=; b=lBjtut3Wkb2f28gewXucs10BEvkIxohj6Zk6LJxNp9hMXqKg0vtpN6kXJsITTfOR0ASOoUmHusecaC+J5PtInOBhk8kRXgxaj5qD/5AbRuEdFPYUEaBZkfhaNQxQEe4qrfqFJWNyvJ0oAIlv/WVWbdForMcdD48b7dRa8gr1bAc= Received: from DM5PR09MB1467.namprd09.prod.outlook.com (10.173.171.21) by DM5PR09MB1466.namprd09.prod.outlook.com (10.173.171.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Sun, 13 Nov 2016 20:48:33 +0000 Received: from DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) by DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) with mapi id 15.01.0721.015; Sun, 13 Nov 2016 20:48:33 +0000 From: "Dang, Quynh (Fed)" To: "ekr@rtfm.com" , "tls@ietf.org" Thread-Topic: Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5 Thread-Index: AQHSPe67hB6sb8v2EES9vmvjfbAsXg== Date: Sun, 13 Nov 2016 20:48:33 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:144:6444:b25c:b655:6dbc] x-microsoft-exchange-diagnostics: 1; DM5PR09MB1466; 7:nWYrY2dyIxWpBqMTdSmTS7dgbuH7tgNSe99nWr5GX5/yonxxMREx9EMw13mweOtSeqkbPK57BT2yUyLwMJDZRPabQMT55bwJPOCdHNt3Dfnn2L2d9FY0Ug3bGea4y3Eyfo7bl8M1Zy9Q7VQX9glDJzXXz48am3k94GRjXhqS2qpQ50GNQUGt3eEw8GPV0TwBakp46ZYtL49dy01Scm0WyKQu5mZrPpbIJsFH+zS2+Frz0jZRvz/Pi6ohJduTTUnzd2ugZCnZqa+7fzQBSOdhHVfSK0D+M6hrLJmamPCWgSfceKug+tqpDTy+Xbsg2QLm8/jiZF6OsiojQv5hCALiRwog+G7n5ZkWMO5TfNQGVuk= x-ms-office365-filtering-correlation-id: 8231d193-22b3-4d01-a2f7-08d40c066ea7 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR09MB1466; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM5PR09MB1466; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1466; x-forefront-prvs: 012570D5A0 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(336003)(199003)(189002)(2900100001)(92566002)(6606003)(9686002)(8936002)(4326007)(6116002)(81166006)(7846002)(77096005)(81156014)(5001770100001)(97736004)(102836003)(122556002)(8676002)(2906002)(19627405001)(586003)(7736002)(189998001)(76576001)(50986999)(3660700001)(106116001)(68736007)(54356999)(105586002)(33656002)(101416001)(2501003)(87936001)(106356001)(99286002)(5660300001)(7696004)(74316002)(3280700002)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1466; H:DM5PR09MB1467.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR09MB1467742B07519F09EE8FA0B2F3BD0DM5PR09MB1467namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2016 20:48:33.0408 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1466 Archived-At: Cc: "cfrg@ietf.org" Subject: [TLS] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 13 Nov 2016 20:48:40 -0000 --_000_DM5PR09MB1467742B07519F09EE8FA0B2F3BD0DM5PR09MB1467namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Eric and all, Regardless of the actual record size, each 128-bit block encryption is perf= ormed with a unique 128-bit counter which is formed by the 96-bit IV and th= e 32-bit counter_block value called CB in NIST SP 800-38D under a given key= as long as the number of encrypted records is not more than 2^64. Assuming a user would like to limit the probability of a collision among 12= 8-bit ciphertext-blocks under 1/2^32, the data limit of the ciphertext ( or= plaintext) is 2^(96/2) (=3D 2^48) 128-bit blocks which is 2^64 bytes. Reading the 2nd paragraph of section 5.5, a user might feel that he/she nee= ds to rekey a lot more quicker than he/she needs. Putting an unnecessarily = low data limit of 2^24.5 full-size records (2^38.5 bytes) also creates an i= ncorrect negative impression (in my opinion) about GCM. I would like to request the working group to consider to revise the text. Regards, Quynh. --_000_DM5PR09MB1467742B07519F09EE8FA0B2F3BD0DM5PR09MB1467namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Eric and all,


Regardless of the actual record size, each 128-bit block encryption is perf= ormed with a unique 128-bit counter which is formed by the 96-bit IV and th= e 32-bit counter_block value called CB in NIST SP 800-38D under a given key= as long as the number of encrypted records is not more than 2^64. 

Assuming a user would like to limit the probability of a collision among 12= 8-bit ciphertext-blocks under 1/2^32, the data limit of the ciphertext ( or= plaintext) is 2^(96/2) (=3D 2^48) 128-bit blocks which is 2^64 bytes. = ;

Reading the 2nd paragraph of section 5.5, a user might feel that he/she nee= ds to rekey a lot more quicker than he/she needs. Putting an unnecessarily = low data limit of 2^24.5 full-size records (2^38.5 bytes) also creates an incorrect negative impression (in my opinion) = about GCM. 

I would like = to request the working group to consider to revise the text.<= /div>

Regards,
Quynh. <= /span>

--_000_DM5PR09MB1467742B07519F09EE8FA0B2F3BD0DM5PR09MB1467namp_-- From nobody Sun Nov 13 14:40:30 2016 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 9FA9F129552 for ; Sun, 13 Nov 2016 14:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 MjhWhoS-43ir for ; Sun, 13 Nov 2016 14:40:27 -0800 (PST) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (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 82C171293D6 for ; Sun, 13 Nov 2016 14:40:27 -0800 (PST) Received: by mail-it0-x231.google.com with SMTP id q124so77696217itd.1 for ; Sun, 13 Nov 2016 14:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=HdJKqiEcKS4tFaK/sIn/2zRO3+o711EhLCNZ1cgbLZg=; b=mXAKN7WTiBIZYpMttDkLGFpBh2Qvc9fo608+6uBI0fbzQeCxrHsb8iA1NXuUn8tWQT oa6A+Dj0NgqbN/10TuNz6/o6kMO/Zk3UAzpMvrhMFd3gpoh9vn9s/8hl+VCDuGAkUwId d23Enw6wrn0xaHCRFradsdEy90TIwcgrAT5To= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=HdJKqiEcKS4tFaK/sIn/2zRO3+o711EhLCNZ1cgbLZg=; b=k8FN/9QBb90Wfty52Lls9xDX6rIvv9U3Na+lIo0MIRgW9L/KpIG1PBzqIaIJNq0dOZ ve/DjxT4z5TMewqpGddrPH1ufi7Is1Vsp2I+eYc/KxVIW53x64HCjnIyVop3mmGwsXoG TXJEKNunDWNyW6E7mMcjf2OlNx9+eJv0E+uglV0KRUU+TpVpF+4KoJTOpGUbVss9U/dT XCeLDSiZmD9r7cGTbqB8MqhFZcRxUC3AfmOBlBz4eiQbMCTuqhRuDuPxRQy6HyTyRrXV RCBC2qnffQRLotDPYYCsYr3sLleB8gF7li5jcnDxIXFgqjzv27JsF0YqRMg6sKK+oXuR c61w== X-Gm-Message-State: ABUngve4+lM3AnNRInxhUcym97bCHKBgUC3sxCLJ4pi7v4a9yT7j5iJo/Kd7QxBy4YR1dQ== X-Received: by 10.202.225.85 with SMTP id y82mr5848957oig.209.1479076826809; Sun, 13 Nov 2016 14:40:26 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:5c48:1ca:d118:de28? ([2001:67c:370:144:5c48:1ca:d118:de28]) by smtp.gmail.com with ESMTPSA id e192sm6582225oic.22.2016.11.13.14.40.25 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Nov 2016 14:40:26 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <38B90783-E685-453F-967C-159CAA49A63E@sn3rd.com> Date: Mon, 14 Nov 2016 07:39:58 +0900 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] TLS sessions' agenda uploaded X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 13 Nov 2016 22:40:28 -0000 I=E2=80=99ve uploaded the agenda and chair slides: https://datatracker.ietf.org/meeting/97/agenda.html Since we=E2=80=99ve got two sessions and the second session conflicts = with tcpinc, if we end up getting through the presentations scheduled = for Wednesday we=E2=80=99ll pull the Friday presentations forward in = this order (based on relevance to TLS1.3): Rebranding (aka PR#612) Example Handshake Traces for TLS 1.3 DTLS spt= From nobody Sun Nov 13 15:01:42 2016 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 A95241294E7 for ; Sun, 13 Nov 2016 15:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 yDs1jp7kOqvB for ; Sun, 13 Nov 2016 15:01:40 -0800 (PST) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (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 3342B129561 for ; Sun, 13 Nov 2016 15:01:40 -0800 (PST) Received: by mail-it0-x22e.google.com with SMTP id q124so69128475itd.1 for ; Sun, 13 Nov 2016 15:01:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=9Jvggqw8iEC/gIbmxdGmuZbQkRHUyKHY+H/TYso42yI=; b=RD7i/ufsIdjoTrZx1Z40NbgGaJET6ODNywzzSsLQFJw+hio6vljAO7S6xTd9n0tceq vvBB6eayEjZr1P/L8x25cT2qOSDaHs9ibTwVlt5Ya7xYcvTP0kzPn7Qjll6EapLjEy5d mN7jYOjB5yKMbp80FSK/TmjZDZfvXhIOH3mkY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=9Jvggqw8iEC/gIbmxdGmuZbQkRHUyKHY+H/TYso42yI=; b=gDFx9yl7aS9YRSSk/GvEnTRR1cbbjwXK3vMrco3f5IY5FzaMerbJ8lUySsX4dxk/Nd I3R8iCWxWIkSXdWn/zkSJjEgG8vNrW/uZS8GSy/1dBcUhkkW12ywmfWlGExzJ3oMVlJu KwlNL0D29sH2VwIoaAs03akp7oSo7Gspl2TY4x1v302P60T0kF5MugEpBHlX2wWtFE6w AC7f+VNLc6ykwWYId95DQTReYU7HYnlzZGbWNgq++9JIQS3P9vbWb5nfiJh+LLcIBtcY K/b8IrM9SeiHbbMawVVmqB4bWp1KDpbLJTkysQ6K1oaW1vJuTZeez+TQFCVQwIO8vU8w I2hg== X-Gm-Message-State: ABUngve3LCXWtqTwR1S3k63DXDUac8OuZfP8oYqJNvV5WMEtnAjpiIl9A3HJ4D6JpOKd0Q== X-Received: by 10.157.4.170 with SMTP id 39mr5909972otm.111.1479078099464; Sun, 13 Nov 2016 15:01:39 -0800 (PST) Received: from [5.5.33.10] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id j61sm6403901otc.26.2016.11.13.15.01.38 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Nov 2016 15:01:39 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <38B90783-E685-453F-967C-159CAA49A63E@sn3rd.com> Date: Mon, 14 Nov 2016 08:01:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <729CF371-40CC-490F-9FE1-02842C294F95@sn3rd.com> References: <38B90783-E685-453F-967C-159CAA49A63E@sn3rd.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] TLS sessions' agenda uploaded X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 13 Nov 2016 23:01:42 -0000 Sorry 1st session is Tuesday not Wednesday: Since we=E2=80=99ve got two sessions and the second session conflicts = with tcpinc, if we end up getting through the presentations scheduled = for *Tuesday* we=E2=80=99ll pull the Friday presentations forward in = this order (based on relevance to TLS1.3): Rebranding (aka PR#612) Example Handshake Traces for TLS 1.3 DTLS spt > On Nov 14, 2016, at 07:39, Sean Turner wrote: >=20 > I=E2=80=99ve uploaded the agenda and chair slides: > https://datatracker.ietf.org/meeting/97/agenda.html >=20 > Since we=E2=80=99ve got two sessions and the second session conflicts = with tcpinc, if we end up getting through the presentations scheduled = for Wednesday we=E2=80=99ll pull the Friday presentations forward in = this order (based on relevance to TLS1.3): >=20 > Rebranding (aka PR#612) > Example Handshake Traces for TLS 1.3 > DTLS >=20 > spt From nobody Sun Nov 13 15:54:26 2016 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 832B412969D for ; Sun, 13 Nov 2016 15:54:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 pKLsFD89kXGW for ; Sun, 13 Nov 2016 15:54:22 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id CE03212969A for ; Sun, 13 Nov 2016 15:54:22 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 30EB116CB9D; Sun, 13 Nov 2016 23:54:22 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 112C616C9E4; Sun, 13 Nov 2016 23:54:22 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479081262; bh=eT+TkoDaXs0U5nSLfvNrraLTJbh3atQCBQNmhqMAFwo=; l=4078; h=From:To:Date:References:In-Reply-To:From; b=tis7r6KG9yctz4bFmiphNJkbrAxiNahQeetcOACYzHN//XTy5ePLLJcJrraNEBVK1 cPHklkJyKX//iHwNhhz92Sao7gd9h50yzMXpeTC80+9HlWdwE8U/zuUG9USjQWG65j m3ePb/RYLFtXvFZrFRTQCB/Pii5SwJNH8FhueQi8= Received: from email.msg.corp.akamai.com (ustx2ex-cas1.msg.corp.akamai.com [172.27.25.30]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 0E2DE9808E; Sun, 13 Nov 2016 23:54:22 +0000 (GMT) Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 13 Nov 2016 17:54:21 -0600 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1178.000; Sun, 13 Nov 2016 17:54:21 -0600 From: "Kaduk, Ben" To: Joseph Salowey , "tls@ietf.org" Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 Thread-Index: AQHSL/2/xyFB68/ah0yZwHLj0TFHDaDXsoAA Date: Sun, 13 Nov 2016 23:54:21 +0000 Message-ID: <13C3DBCF-2609-4560-A194-1FA422BE7EEE@akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.95] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 13 Nov 2016 23:54:24 -0000 SSBoYXZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQgYW5kIGhhdmUgYSBmZXcgbWlub3IgY29tbWVu dHMuICBJIGFsc28gaGF2ZSBtYW55IGVkaXRvcmlhbCBub3RlcyB0aGF0IGNhbiBiZSBhZGRyZXNz ZWQgb3V0IG9mIGJhbmQuDQoNCkluIHRoZSBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9uLCB3ZSBo YXZlIHRleHQgYWJvdXQgdGhlIHByb3BlcnRpZXMgdGhhdCBUTFMgaXMgZXhwZWN0ZWQgdG8gcHJv dmlkZSwgbGlrZSBjb25maWRlbnRpYWxpdHksIGF1dGhlbnRpY2F0aW9uLCBldGMuICBEbyB3ZSB3 YW50IHRvIHNheSBhbnl0aGluZyBhYm91dCBhdm9pZGluZyBzaWRlIGNoYW5uZWxzIHRoYXQgbWln aHQgbGVhayBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZGF0YSBiZWluZyBleGNoYW5nZWQ/ICBJIGtu b3cgdGhhdCB3ZSBhcmUgbm90IDEwMCUgY29uZmlkZW50IGF0IHdoYXQgZXhhY3RseSB3ZSBjdXJy ZW50bHkgYWNoaWV2ZSBpbiB0aGlzIGFyZWEsIGJ1dCBzaW5jZSB3ZSBoYXZlIG1lY2hhbmlzbXMg dGhhdCBhdHRlbXB0IHRvIGFjaGlldmUgaXQsIG1heWJlIGl0IGlzIHdvcnRoIG1lbnRpb25pbmcu ICAoSW4gYSBzaW1pbGFyIHZlaW4sIGFzIGRhdmlkYmVuIHJlbWluZGVkIG1lIHJlY2VudGx5LCBh biBhdHRhY2tlciDigJx3aG8gaGFzIGNvbXBsZXRlIGNvbnRyb2wgb2YgdGhlIG5ldHdvcmvigJ0s IGFzIGlzIG91ciBzdGF0ZWQgYWR2ZXJzYXJ5LCBjYW4gZG8gdGhpbmdzIGxpa2UgdHJpY2tsZSBw YWNrZXRzIGluIG9uZSBieSBvbmUgYW5kIHRyeSB0byBzZWUsIGUuZy4sIHdoZXJlIHRoZSBlbmQg b2YgZWFybHkgZGF0YSBpcyBhbmQgcXVlcnkgaGFuZHNoYWtlIHN0YXRlLiAgU28gc29tZSB0aGlu Z3MgbWF5IG5vdCBiZSBhdm9pZGFibGUuKQ0KDQpJbiBzZWN0aW9uIDQuMi41LjEgd2UgdGFsayBh Ym91dCBob3cgZm9yIEZGREggcGVlcnMgU0hPVUxEIHZhbGlkYXRlIGVhY2ggb3RoZXLigJlzIHB1 YmxpYyBrZXkgWSBieSBlbnN1cmluZyB0aGF0IDEgPCBZIDwgcC0xLCB3aGljaCBpcyBzdXBwb3Nl ZCB0byBlbnN1cmUgdGhhdCB0aGUgcGVlciBpcyB3ZWxsLWJlaGF2ZWQgYW5kIGlzbuKAmXQgZm9y Y2luZyB0aGUgbG9jYWwgc3lzdGVtIGludG8gYSBzbWFsbCBzdWJncm91cC4gIFNvbWVob3cgSSB0 aG91Z2h0IHRoYXQgYWRkaXRpb25hbCBjaGVja3Mgd2VyZSBuZWVkZWQgdG8gYXZvaWQgYmVpbmcg Zm9yY2VkIGludG8gYSBzbWFsbCBzdWJncm91cCwgYnV0IEkgZ3Vlc3MgdGhhdCBkZXBlbmRzIG9u IHdoYXQgZ3JvdXAgaXTigJlzIGluLCBhbmQgSSBkaWRu4oCZdCBwdWxsIHVwIHRoZSBSRkMgNzkx OSByZWZlcmVuY2Ugd2hlbiBJIHdhcyByZWFkaW5nIHRoaXMgZG9jdW1lbnQuDQoNCkluIHNlY3Rp b24gNC4yLjcsIHdlIG5vdGUgdGhhdCB0aGUgc2VydmVyIE1VU1QgTk9UIHNlbmQgdGhlIOKAnHBz a19rZXlfZXhjaGFuZ2VfbW9kZXPigJ0gZXh0ZW5zaW9uLCB3aXRoIHRoZSBpbXBsaWNhdGlvbiB0 aGF0IHRoZSBjbGllbnQgbXVzdCBvYnNlcnZlciB0aGUgdHlwZXMgb2YgaGFuZHNoYWtlIG1lc3Nh Z2VzIHRoYXQgYXJlIHN1YnNlcXVlbnRseSByZWNlaXZlZCBpbiBvcmRlciB0byBkZXRlcm1pbmUg d2hhdCB0aGUgc2VydmVyIHNlbGVjdGVkLiAgSSB0aGluayB0aGF0IHdlIGhhZCB0YWxrZWQgYWJv dXQgdGhpcyBhbHJlYWR5IHNvbWUgdGltZSBhZ28sIGJ1dCBqdXN0IHdhbnRlZCB0byBjb25maXJt IHRoYXQgd2UgYXJlIG9rYXkgd2l0aCBpbmNyZWFzaW5nIHRoZSBzaXplIG9mIHRoZSBjbGllbnQg c3RhdGUgbWFjaGluZSBpbiB0aGlzIG1hbm5lci4NCg0KSW4gc2VjdGlvbiA0LjUuMSB3ZSBub3Rl IHRoYXQgd2hlbiBjbGllbnQgYXV0aCBpcyBub3QgdXNlZCwgc2VydmVycyBNQVkgY29tcHV0ZSB0 aGUgcmVtYWluZGVyIG9mIHRoZSBjbGllbnQtc2VudCBtZXNzYWdlcyBmb3IgdGhlIHRyYW5zY3Jp cHQgc28gYXMgdG8gaXNzdWUgYSBOZXdTZXNzaW9uVGlja2V0IGltbWVkaWF0ZWx5IGFmdGVyIHRo ZSBzZXJ2ZXIgRmluaXNoZWQuICBEbyB3ZSB3YW50IHRvIHNheSBhbnl0aGluZyBhYm91dCB3aHkg YSBzZXJ2ZXIgbWlnaHQgd2lzaCB0byBkbyBzbz8NCg0KVGhlIGNvdmVyYWdlIG9mIHJlY29yZCBw YXlsb2FkIHByb3RlY3Rpb24gKGFyb3VuZCBzZWN0aW9uIDUuMikgc2VlbXMgdG8gbm90IGFsd2F5 cyBtYWtlIGNhcmVmdWwgZGlzdGluY3Rpb24gYmV0d2VlbiBUTFNQbGFpbnRleHQsIFRMU0NpcGhl cnRleHQsIFRMU0lubmVyUGxhaW50ZXh0LCBhbmQgdGhlIGZpZWxkcyB0aGVyZWluLiAgSW4gc29t ZSBzZW5zZSB0aGlzIGlzIGVkaXRvcmlhbCwgYnV0IHRoZXJlIHdlcmUgYSBsb3Qgb2YgcGxhY2Vz IHRoYXQgSSBmbGFnZ2VkLCBzbyBJIHdhbnRlZCB0byBjYWxsIGl0IG91dCB0byB0aGUgYnJvYWRl ciBhdWRpZW5jZSBhbmQgZ2V0IG1vcmUgZXllcyBvbiBpdC4gIEkgYWxzbyBkaWRu4oCZdCBmaW5k IGEgZGVzY3JpcHRpb24gb2Ygd2hlcmUgdGhlIGxlbmd0aCBvZiB0aGUgQUVBRCBhdXRoZW50aWNh dGlvbiB0YWcgZ2V0cyBpbmNsdWRlZCBpbnRvIGEgbGVuZ3RoIGZpZWxkIGZvciB0aGUgY2lwaGVy dGV4dC4NCg0KQXQgdGhlIGVuZCBvZiBzZWN0aW9uIDYuMSB3ZSBoYXZlIHRoaXMgbGl0dGxlIG5v dGUgdGhhdCDigJxpdCBpcyBhc3N1bWVkIHRoYXQgY2xvc2luZyBhIGNvbm5lY3Rpb24gcmVsaWFi bHkgZGVsaXZlcnMgcGVuZGluZyBkYXRhIGJlZm9yZSBkZXN0cm95aW5nIHRoZSB0cmFuc3BvcnTi gJ0sIHdoaWNoLCBpZiBJIHJlbWVtYmVyIGNvcnJlY3RseSBwcmV2aW91cyBkaXNjdXNzaW9uIG9u IHRoaXMgbGlzdCwgaXMgbm90IGFjdHVhbGx5IHRydWUgZm9yIGxpbnV4LiAgSXQgaXMgcGVyaGFw cyBwcm9ibGVtYXRpYyB0byBoYXZlIGFuIGFzc3VtcHRpb24gdGhhdCB3ZSBrbm93IGlzIG5vdCBn b2luZyB0byBiZSBoZWxkIGZvciBhIGxhcmdlIHByb3BvcnRpb24gb2YgaW1wbGVtZW50YXRpb25z Lg0KDQotQmVuDQoNCg== From nobody Sun Nov 13 15:54:43 2016 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 E602C12969A; Sun, 13 Nov 2016 15:54:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rCZ7GtVSBNPl; Sun, 13 Nov 2016 15:54:23 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 C8F5712968E; Sun, 13 Nov 2016 15:54:22 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n21so78359762qka.3; Sun, 13 Nov 2016 15:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jOBBQY8obNo/71Ywzqd49r+pzmsmwnA9uJ5FZjT3orM=; b=cJhCeqwvgHZU9C2/Nu0CBiEuUqVKec0hwtEBs/gdXuvlPfLc9xe5CfECbC5/hx/ItY UK1UvooMEoI+O9Bc3lkKJrP5LhsZE0ACk1gjwO7gW7qhByQkCgXjL9SAfJnH31GUdwEi WVbjYOtrdv0vV/H61RIS/n6Cko3RQIUgGDV6t73A+tttkQ/mMCZ73GR0NC5EuclnEAxv UCbEzUufHuHW0joj8jIF9XY9MLERVcy5Zaipfr9UI3Lf4DOAlUFjxZJYq3RKVJC5OBL1 mcnrOLNiUb0b4XOqr8TzuSOofSGf2CKGRJSvZClOIm+kFjt/wYhZxDBywpwzGCVCvrkN x8Ig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jOBBQY8obNo/71Ywzqd49r+pzmsmwnA9uJ5FZjT3orM=; b=dtWdX9jlcf43ZBB3VNH5CiC4BXA+YcZSnXSNWN1ltJXXn9Adx7d22r/sJiXltWgj78 E4aYNtJ9NNwcNyYuAOaNonE4dkqmWqMTvhhEXpy4zC3rps9XYsez4bWAf0trGTaPt25M jtBdF/A0pOdT/mZEJ3CZQYjwX+qR1mFSoPGi+24N1aXO+SlD5+GE0hmGTbmerTNt+lMN uMRAsTse/VCOskBfIHukIT/Zm3fcG1qtLCem4GB7noTT9zKziJlipYmh0Wwu2toiounp tUyoGhRuIeIGjacNJtMF3DUSfyda00YLtwYOOlFKiNPwgOM+4jq3KPVmb5UqHum7JiiW gpqA== X-Gm-Message-State: ABUngvfcwRpvRESkMUIiLomd/TWGnpxkT6Bpdykdc6e3ufLfIjS1+rSmapByZPa+Gqfw1aOW0kiBAR4sIZ2tmw== X-Received: by 10.55.12.2 with SMTP id 2mr14058151qkm.68.1479081261915; Sun, 13 Nov 2016 15:54:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 13 Nov 2016 15:54:21 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 14 Nov 2016 08:54:21 +0900 Message-ID: To: "Dang, Quynh (Fed)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "cfrg@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 13 Nov 2016 23:54:26 -0000 These are intentionally very conservative. Having implemented this, I find it OK. The text cites its sources. Reading those sources corrects any misapprehension. The key point here is that we want to ensure that the initial - maybe uninformed - inferences need to be for the safe thing. We don't want to have the situation where we have looser text and that leads to mistakes. For instance, someone could deploy code that assumes a certain "average" record size based on a particular deployment and hence a larger limit. If the deployment characteristics change without the code changing we potentially have an issue. You really need to demonstrate that there is harm with the current text. if rekeying happens on that timescale (which is still very large), that's not harmful. I'm concerned that we aren't going to rekey often enough. I don't agree that it will create any negative perception of GCM. On 14 November 2016 at 05:48, Dang, Quynh (Fed) wrote: > Hi Eric and all, > > > Regardless of the actual record size, each 128-bit block encryption is > performed with a unique 128-bit counter which is formed by the 96-bit IV and > the 32-bit counter_block value called CB in NIST SP 800-38D under a given > key as long as the number of encrypted records is not more than 2^64. > > Assuming a user would like to limit the probability of a collision among > 128-bit ciphertext-blocks under 1/2^32, the data limit of the ciphertext ( > or plaintext) is 2^(96/2) (= 2^48) 128-bit blocks which is 2^64 bytes. > > Reading the 2nd paragraph of section 5.5, a user might feel that he/she > needs to rekey a lot more quicker than he/she needs. Putting an > unnecessarily low data limit of 2^24.5 full-size records (2^38.5 bytes) also > creates an incorrect negative impression (in my opinion) about GCM. > > I would like to request the working group to consider to revise the text. > > Regards, > Quynh. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > From nobody Sun Nov 13 17:11:00 2016 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 92D741294A3 for ; Sun, 13 Nov 2016 17:10:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ShT3m7nrDkQP for ; Sun, 13 Nov 2016 17:10:53 -0800 (PST) Received: from mail-qt0-x234.google.com (mail-qt0-x234.google.com [IPv6:2607:f8b0:400d:c0d::234]) (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 0AAB9129698 for ; Sun, 13 Nov 2016 17:10:53 -0800 (PST) Received: by mail-qt0-x234.google.com with SMTP id p16so39322262qta.0 for ; Sun, 13 Nov 2016 17:10:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=tNNpJ8sDVjgwAEUDuCCE4VrpvuG+7YeCIiqWRkuzaoY=; b=bKw8ov6vV+I2uZGO6TvuU8SUcmAi3NwYcb2MGKAwsof5M5l+sw0UqoYrQVMeJbFH0z x7pQ6+578DQwofmHHhbs4MONf/0Xf7V8eWoRmzWdj9tXp9d+cCGwUDzuwx9jQyT5JDU/ WiatIDl14JAn2W4AGQ+N/fhCldrkyfK1v31YJfojUBeekd4B6xITA7UCGwvkNJb88x4G rlvrmhIXLAAeqAdNQq+wDivSEQ4xeefuiDt+KMY4+2JJjK+IEC4yfyMQLI8HB9rE7Wws hLMtVXBmbB4O709cY61oj4cNqsiVoswwAtT5FM4O5SlNt/q0hDv1OCzdtXNFffAtLyyc 4rPQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=tNNpJ8sDVjgwAEUDuCCE4VrpvuG+7YeCIiqWRkuzaoY=; b=JN/U7tnNV9YxGTaRlGMrnTfx+jNqIl/CvLYerdcVgEuI16L6hIm5E4MZHicB4i3bed UgbyDeBKXGhpp+b/Act1WhSdAp7A6veK1f4hgawJEpdYOWU0ChRMFK1ON2U3R2dB6LbB 7D2Ya1N5bky55sTIVCLcnNReD0XaF3Cnw1b3XQfiUrUX8YxXImMI6W9LNE0fp9StCSEb 7FzxB6j9ZN62wisUuOQ7CbkjM1qk7Q7VQ3uWSdip9GZYRN5jINMZqaaLXjUHUkeFyQp0 FbEuO1Y5uJW+VgdTY+/5H3ZAd5CNIfJbc+8hHA1/llqxfedSpOQ3AHWLLLDIfGXaSoHV 0vww== X-Gm-Message-State: ABUngvcV2H4HtS3KNrhvY44s/X9xPhPyGCGrGOsTryQVMewVv3OmVP+1MVnbYc7PjiF920epCzeLvqe6+rzQeQ== X-Received: by 10.200.48.28 with SMTP id f28mr6338270qte.247.1479085852114; Sun, 13 Nov 2016 17:10:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Sun, 13 Nov 2016 17:10:51 -0800 (PST) In-Reply-To: <147908236337.5607.3896025791064163090.idtracker@ietfa.amsl.com> References: <147908236337.5607.3896025791064163090.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Mon, 14 Nov 2016 10:10:51 +0900 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-thomson-tls-tls13-vectors-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 01:10:57 -0000 I've updated the test vectors draft. The vectors should now be correct with respect to draft-18. I implemented exporters as well, so calculations for those are now shown. ---------- Forwarded message ---------- From: Date: 14 November 2016 at 09:12 Subject: New Version Notification for draft-thomson-tls-tls13-vectors-01.txt To: Martin Thomson A new version of I-D, draft-thomson-tls-tls13-vectors-01.txt has been successfully submitted by Martin Thomson and posted to the IETF repository. Name: draft-thomson-tls-tls13-vectors Revision: 01 Title: Example Handshake Traces for TLS 1.3 Document date: 2016-11-13 Group: Individual Submission Pages: 28 URL: https://www.ietf.org/internet-drafts/draft-thomson-tls-tls13-vectors-01.txt Status: https://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ Htmlized: https://tools.ietf.org/html/draft-thomson-tls-tls13-vectors-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-thomson-tls-tls13-vectors-01 Abstract: Examples of TLS 1.3 handshakes are shown. Private keys and inputs are provided so that these handshakes might be reproduced. Intermediate values, including secrets, traffic keys and ivs are shown so that implementations might be checked incrementally against these values. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat From nobody Sun Nov 13 17:36:34 2016 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 1C8241295F0 for ; Sun, 13 Nov 2016 17:36:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 dlIYUWFi1RAw for ; Sun, 13 Nov 2016 17:36:30 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 7D8B8129577 for ; Sun, 13 Nov 2016 17:36:30 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id q124so74740493itd.1 for ; Sun, 13 Nov 2016 17:36:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=g35d17W5MFWo/FY0Y/eaAZ8xZebTr2/z7TVXf+lURh8=; b=IdvB//AoZVLk1qD572rCwDOQwJSrk7ql3EgVb74RIs9K5Wy5jVvd2dHM0cj66imLzQ 81ZC04bSROSaHAqZcLK6C0EiFdKAR0MpjSzIHYxkDR4acYWaBTleyLpMCDdterUlgo0q BjAjUwFF6vvCJQmuaKnaZxxETmE79CaSiNsT8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=g35d17W5MFWo/FY0Y/eaAZ8xZebTr2/z7TVXf+lURh8=; b=j4bqFJfzQ27w3cDltjSPWXMgBJ+ZAquI5W7vMzroqvpo5+f5HK/rjWGrFNZijtNz5/ CZTOCvkOKWvmkM15MiBoHA3jW9rjaEBggl1JiQlpwjhoFg+IeULyrlHQWEnyeEYN98zn wJYpgfDgIDCf3wuW3CzuTfYAM9NROyC8LEP1BKvK/EnQzr/Rken40F9Fg9hZ+bjyzcy7 zwDmIAp7c5SsWKNVxuy3Nwkyx/yWW4IBm2pD9wlclACae3FswZxO+NHPx+ZA2NTTDPKJ 0lybpp1a4TaODqSJya8MSJkY+rk0lVD+5XFh+w0XJTW7+YctO4XzkJYFBN410djjfY+0 SSxg== X-Gm-Message-State: ABUngvdS/pWUb9wbWwb/FN+u+AtMu+/kDjg9HdnmMXDKT+n7i1LJb6n4Rho0W0AZqAEjgA== X-Received: by 10.157.50.138 with SMTP id u10mr5375001otb.83.1479087389800; Sun, 13 Nov 2016 17:36:29 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:b00c:1764:9887:3b26? ([2001:67c:370:128:b00c:1764:9887:3b26]) by smtp.gmail.com with ESMTPSA id t184sm6666924oie.21.2016.11.13.17.36.28 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Nov 2016 17:36:29 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: Date: Mon, 14 Nov 2016 10:36:02 +0900 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] housekeeping: uplift RFC 5289 to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 01:36:32 -0000 This email addresses the "Uplifting=E2=80=9D bullet on slide 6 of the = chair slides = (https://www.ietf.org/proceedings/97/slides/slides-97-tls-tls-wg-chair-sli= des-00.pdf); this is entirely procedural (i.e., there=E2=80=99s really = no technical ). The cipher suite registry's new "WG recommended=E2=80=9D column's =E2=80=9C= Y" values are being populated with cipher suites that are on standards = track. The notable exceptions are the EC-based AES-GCM ciphers defined = in RFC 5289, which is an informational RFC. This point is buried in an = earlier version of draft-ietf-tls-tls13 and now in the soon to be = draft-ietf-tls-iana-registry-updates (was = draft-sandj-tls-iana-registry-updates); the complete list of the pet-TLS = 1.3 suites can be found here: = https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01#secti= on-6. We can uplift RFC 5289 to PS from Informational with what essentially = amounts to an IETF LC; we don't need a new draft (there's no errata). = We want to know if there are any objections to starting this process = please post a message to the list by November 21st if you object (and = why). Please note the following: - This "action" is similar to what we're doing with 4492bis (it too is = being moved to standards track) it's just that we can use this other = process. - RFC 7525, which was published through the UTA WG and is a BCP btw, = already 2119-RECOMMENDs the ciphers. - RFC 7540 (aka HTTP/2) MUSTs one of the RFC 5289 cipher suites. spt= From nobody Sun Nov 13 17:45:31 2016 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 5808112969C for ; Sun, 13 Nov 2016 17:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 GPw88bvosrY5 for ; Sun, 13 Nov 2016 17:45:24 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 BBCE1129649 for ; Sun, 13 Nov 2016 17:45:22 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id a184so20123848ybb.0 for ; Sun, 13 Nov 2016 17:45:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=iEtt9UaP8olN1xH8om9Eu+aWdA7Crp8VLbcMv9ZsyyM=; b=UZAU3vcL1uA1I/Q8hhCtg50sqhyn9m4Vrp3DUh0wDdo2ejviD6dc+ZnmxXcor0dv2Y rYi3dKIdL5DNUoTxtR5NR7eLWrBzvuDaU2JHulUnS1qIED26UFOgC9pKfXnLR80wdaOZ QTaovxBcp7ipCVHlXsdCUUqo7Upg/6VCvDreEgCPQAxbeOSiGervR02K2gjCQ2b3wRTF kMphzqZGRkVnOEihnUy86t6R06nrYsCal1w3TAq6VSnA3aPkTLD5SuTyToBysSMYw/c2 8AFx4Vm2dTYICx+V3Lk8qMp3Z7h113JkbQ7VIKgzQOeCdRJfWwrxR4hNwTxaSp6imxgh Cf8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iEtt9UaP8olN1xH8om9Eu+aWdA7Crp8VLbcMv9ZsyyM=; b=ctcJ5BVoZ/MZn78VrQZ+GOYx+xwGuUsU2p9eYMQf4y5j9i81+0AGb0+uQcwWkwXJyB c5t1fC1Cp7D70Xp2PrYl4GZPvPKK5bLB06oxY1Wi5e+UoMTnTUSo/gnDmCOtW6CRR6BZ TwxIPNgRW3ecHfXzheQXAOK0n9P7FjZUAp6/7m3cmTX/sjju/U3UjcpIGCDlOvacgmDw ZOzHXrGnYO57VH/JnJoRdpJeRsScxYH9Pvk9qw8uA9vTNO2hiTywGrga76inqiqiX5vm i/shAg7SSwSuPMrn3lc9+BOw7A4HWg53F8vt8T20gGnJ56aWzGFog6nveIGLkIKllTm0 30Lw== X-Gm-Message-State: ABUngvcS5oqvehHSrqsmuXbxCNwGrtoHSQFcaSy2/t8UpGB8ZVVZkZJtwqCsUttFYT86GC1eHW6pJ/+n8EPTDg== X-Received: by 10.37.246.9 with SMTP id t9mr13406655ybd.107.1479087921990; Sun, 13 Nov 2016 17:45:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sun, 13 Nov 2016 17:44:41 -0800 (PST) In-Reply-To: <13C3DBCF-2609-4560-A194-1FA422BE7EEE@akamai.com> References: <13C3DBCF-2609-4560-A194-1FA422BE7EEE@akamai.com> From: Eric Rescorla Date: Mon, 14 Nov 2016 10:44:41 +0900 Message-ID: To: "Kaduk, Ben" Content-Type: multipart/alternative; boundary=f403045db0742ebf55054138fe7c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 01:45:30 -0000 --f403045db0742ebf55054138fe7c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben wrote: > I have reviewed this document and have a few minor comments. I also have > many editorial notes that can be addressed out of band. > > In the abstract and introduction, we have text about the properties that > TLS is expected to provide, like confidentiality, authentication, etc. D= o > we want to say anything about avoiding side channels that might leak > information about the data being exchanged? I know that we are not 100% > confident at what exactly we currently achieve in this area, but since we > have mechanisms that attempt to achieve it, maybe it is worth mentioning. > (In a similar vein, as davidben reminded me recently, an attacker =E2=80= =9Cwho has > complete control of the network=E2=80=9D, as is our stated adversary, can= do things > like trickle packets in one by one and try to see, e.g., where the end of > early data is and query handshake state. So some things may not be > avoidable.) > I'd be interested in seeing a PR in this area. In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each > other=E2=80=99s public key Y by ensuring that 1 < Y < p-1, which is suppo= sed to > ensure that the peer is well-behaved and isn=E2=80=99t forcing the local = system > into a small subgroup. Somehow I thought that additional checks were > needed to avoid being forced into a small subgroup, but I guess that > depends on what group it=E2=80=99s in, and I didn=E2=80=99t pull up the R= FC 7919 reference > when I was reading this document. > These are the recommendations in 7919, I believe > In section 4.2.7, we note that the server MUST NOT send the > =E2=80=9Cpsk_key_exchange_modes=E2=80=9D extension, with the implication = that the client > must observer the types of handshake messages that are subsequently > received in order to determine what the server selected. I think that we > had talked about this already some time ago, but just wanted to confirm > that we are okay with increasing the size of the client state machine in > this manner. > It's not subsequent messages. You determine it from the PreSharedKey and KeyShare extensions. > In section 4.5.1 we note that when client auth is not used, servers MAY > compute the remainder of the client-sent messages for the transcript so a= s > to issue a NewSessionTicket immediately after the server Finished. Do we > want to say anything about why a server might wish to do so? > I think I would rather not. The coverage of record payload protection (around section 5.2) seems to not > always make careful distinction between TLSPlaintext, TLSCiphertext, > TLSInnerPlaintext, and the fields therein. In some sense this is > editorial, but there were a lot of places that I flagged, so I wanted to > call it out to the broader audience and get more eyes on it. I also didn= =E2=80=99t > find a description of where the length of the AEAD authentication tag get= s > included into a length field for the ciphertext. > I'm not following this point. The way to think about this is that the ciphertext is a specific size. That may be encryption + auth tag or not (it's possible to design an AEAD algorithm that doesn't have a separate auth tag). -Ekr At the end of section 6.1 we have this little note that =E2=80=9Cit is assu= med that > closing a connection reliably delivers pending data before destroying the > transport=E2=80=9D, which, if I remember correctly previous discussion on= this > list, is not actually true for linux. It is perhaps problematic to have = an > assumption that we know is not going to be held for a large proportion of > implementations. > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f403045db0742ebf55054138fe7c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben <bkaduk@akamai.com>= wrote:
I have reviewed this docum= ent and have a few minor comments.=C2=A0 I also have many editorial notes t= hat can be addressed out of band.

In the abstract and introduction, we have text about the properties that TL= S is expected to provide, like confidentiality, authentication, etc.=C2=A0 = Do we want to say anything about avoiding side channels that might leak inf= ormation about the data being exchanged?=C2=A0 I know that we are not 100% = confident at what exactly we currently achieve in this area, but since we h= ave mechanisms that attempt to achieve it, maybe it is worth mentioning.=C2= =A0 (In a similar vein, as davidben reminded me recently, an attacker =E2= =80=9Cwho has complete control of the network=E2=80=9D, as is our stated ad= versary, can do things like trickle packets in one by one and try to see, e= .g., where the end of early data is and query handshake state.=C2=A0 So som= e things may not be avoidable.)

I'd= be interested in seeing a PR in this area.


In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each ot= her=E2=80=99s public key Y by ensuring that 1 < Y < p-1, which is sup= posed to ensure that the peer is well-behaved and isn=E2=80=99t forcing the= local system into a small subgroup.=C2=A0 Somehow I thought that additiona= l checks were needed to avoid being forced into a small subgroup, but I gue= ss that depends on what group it=E2=80=99s in, and I didn=E2=80=99t pull up= the RFC 7919 reference when I was reading this document.
<= div>
These are the recommendations in 7919, I believe


In section 4.2.7, we note that the server MUST NOT send the =E2=80=9Cpsk_ke= y_exchange_modes=E2=80=9D extension, with the implication that the client m= ust observer the types of handshake messages that are subsequently received= in order to determine what the server selected.=C2=A0 I think that we had = talked about this already some time ago, but just wanted to confirm that we= are okay with increasing the size of the client state machine in this mann= er.

It's not subsequent messages. Y= ou determine it from the PreSharedKey and KeyShare extensions.

In section 4.5.1 we note that when client auth is not used, servers MAY com= pute the remainder of the client-sent messages for the transcript so as to = issue a NewSessionTicket immediately after the server Finished.=C2=A0 Do we= want to say anything about why a server might wish to do so?

I think I would rather not.


The coverage of record payload protection (around section 5.2) seems to not= always make careful distinction between TLSPlaintext, TLSCiphertext, TLSIn= nerPlaintext, and the fields therein.=C2=A0 In some sense this is editorial= , but there were a lot of places that I flagged, so I wanted to call it out= to the broader audience and get more eyes on it.=C2=A0 I also didn=E2=80= =99t find a description of where the length of the AEAD authentication tag = gets included into a length field for the ciphertext.
=
I'm not following this point. The way to think about thi= s is that the ciphertext is a specific size. That may be encryption + auth = tag or not (it's possible to design an AEAD algorithm that doesn't = have a separate auth tag).

-Ekr

At the end of section 6.1 we have this little note that =E2=80=9Cit is assu= med that closing a connection reliably delivers pending data before destroy= ing the transport=E2=80=9D, which, if I remember correctly previous discuss= ion on this list, is not actually true for linux.=C2=A0 It is perhaps probl= ematic to have an assumption that we know is not going to be held for a lar= ge proportion of implementations.

-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--f403045db0742ebf55054138fe7c-- From nobody Sun Nov 13 18:22:03 2016 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 BB0171294FC for ; Sun, 13 Nov 2016 18:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 DlwJfNU311sh for ; Sun, 13 Nov 2016 18:22:00 -0800 (PST) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 461771294AE for ; Sun, 13 Nov 2016 18:22:00 -0800 (PST) Received: by mail-it0-x22a.google.com with SMTP id c20so54973553itb.0 for ; Sun, 13 Nov 2016 18:22:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=5HDe274rdPd+ek8pUzUAgURJwtn1NcKxTnBtXDob3qE=; b=OXvH3Pa9wlApalZcxiLYVOzOI4ZN/3Un3//oE76HC/3b/lkpTKprv6DvP0bK4YObAT BvERJAjRDb0Ob972Wc02iTWDxQD8JsdMOAcR8LeN6vR6QsacERt9TlkqB3LbYmUT02RZ DQdR6Z25AW2Np0rcJKkVE3B43/9sCvjyNc+IWbvpc6jndPidK5eqzA8G/XsNWfvt9/Ej 4xcVFNeRvJov/+TAAGT9pLuGSJKMUhs7uYfSHeVwtxThQTDIT8p8j3J0FFSJebPjgG/D g06V7IgizLOyo0+fxvN9NARZuHhgOKTNDg0WvDn0Hpr3FBG7SlfuPxRC72vSLcJapkI1 KXvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=5HDe274rdPd+ek8pUzUAgURJwtn1NcKxTnBtXDob3qE=; b=RQnoC0/ES/Cnf8ycV3qxuNvvLANzpwP/kTL0YYCKnnfO96YvO6xlx8I1QMjuahPYgp Xjc0oxhD0qgzNLyq03IczaovCoNSp5jZzecboiPpbZwUjT61BMwvd0mgyCS0g34yT82V 2OMwwDxGKW/z+qc5DnGaEobbl7SVhApQ5J/wY88+9TZI7FOK8hC0gXqbv9I5E5/SpjbH 1dCSDEGxZDItQg0INmyYRsPR19pCKL0kko6qM8u1rtHV8D6vfhQE0mAmScrGowU4D4iU rQ5hXF7Rih7cmDQc3RI8kyyXgkjHcHxhE3BhQd+2sAgJnylahiL0FagGNJLTArbRKogW q8VQ== X-Gm-Message-State: ABUngvfajTyhJifPnZ50w4yAFKMzv1s172vm+/ofnu3ELRbKbMBrBAztb+Gn5ZbRyg9gVh04w58wq6X4k6qdTw== X-Received: by 10.107.179.195 with SMTP id c186mr11244470iof.35.1479090119687; Sun, 13 Nov 2016 18:21:59 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.32.10 with HTTP; Sun, 13 Nov 2016 18:21:58 -0800 (PST) In-Reply-To: <20161108060747.GA8585@LK-Perkele-V2.elisa-laajakaista.fi> References: <7D3571C9-9873-4D88-9666-A47D0CD77671@sn3rd.com> <1470821613.2539.44.camel@redhat.com> <20161018163104.GA2405@LK-Perkele-V2.elisa-laajakaista.fi> <20161108060747.GA8585@LK-Perkele-V2.elisa-laajakaista.fi> From: Daniel Migault Date: Sun, 13 Nov 2016 21:21:58 -0500 X-Google-Sender-Auth: y9AkCs3meIIx9-PsAFTW11b6czE Message-ID: To: Ilari Liusvaara Content-Type: multipart/alternative; boundary=001a114848302cc3c105413981b3 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 02:22:02 -0000 --001a114848302cc3c105413981b3 Content-Type: text/plain; charset=UTF-8 done. Thanks for the review! Yours Daniel On Tue, Nov 8, 2016 at 1:07 AM, Ilari Liusvaara wrote: > On Mon, Nov 07, 2016 at 10:16:13PM -0500, Daniel Migault wrote: > > Hi, > > > > The current draft is only considering TLS1.2. TLS1.3 is only mentioned > for > > advocating AEAD. > > > > Do you think we should add text that details how to proceed with TLS1.3 ? > > If so what do you think of the following text ? > > That is, I think the dependency on TLS 1.3 should be downgraded to > informative (unless that has already been done). > > > > > Yours, > > Daniel > > > > The assigned code points are only expected to be used for TLS1.2. > > TLS1.3 does not follow the same name convention. Instead TLS1.3 > > cipher suites are designated according to the AEAD suite as well as > > the hash function used. The current combination of AEAD algorithms > > and Hash fucntion are already defined in TLS.1.3 so there is no need > > to add additional cipher suites for TLS1.3. > > Seems reasonable. > > > Instead, in order to used the following ECDHE_PSK authentication > > method. TLS1.3 uses a combination of the "key_share" and > > "psk_key_exchange_modes" extentions. "psk_key_exchange_modes" > > extension sets its mode to psk_dhe_ke. The "key_share" extention > > contains a KeyShareEntry structure that carries the ECDHE parameters. > > > > I think 'used the following' -> 'use the' and first period should be > comma. > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114848302cc3c105413981b3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
done.

Thanks for the review!
Yours

Daniel
<= br>
On Tue, Nov 8, 2016 at 1:07 AM, Ilari Liusvaa= ra <ilariliusvaara@welho.com> wrote:
On Mon, Nov 07, 2016 at 10:16:13PM -0500= , Daniel Migault wrote:
> Hi,
>
> The current draft is only considering TLS1.2. TLS1.3 is only mentioned= for
> advocating AEAD.
>
> Do you think we should add text that details how to proceed with TLS1.= 3 ?
> If so what do you think of the following text ?

That is, I think the dependency on TLS 1.3 should be downgraded to informative (unless that has already been done).

>
> Yours,
> Daniel
>
>=C2=A0 =C2=A0 The assigned code points are only expected to be used for= TLS1.2.
>=C2=A0 =C2=A0 TLS1.3 does not follow the same name convention.=C2=A0 In= stead TLS1.3
>=C2=A0 =C2=A0 cipher suites are designated according to the AEAD suite = as well as
>=C2=A0 =C2=A0 the hash function used.=C2=A0 The current combination of = AEAD algorithms
>=C2=A0 =C2=A0 and Hash fucntion are already defined in TLS.1.3 so there= is no need
>=C2=A0 =C2=A0 to add additional cipher suites for TLS1.3.

Seems reasonable.

>=C2=A0 =C2=A0 Instead, in order to used the following ECDHE_PSK authent= ication
>=C2=A0 =C2=A0 method.=C2=A0 TLS1.3 uses a combination of the "key_= share" and
>=C2=A0 =C2=A0 "psk_key_exchange_modes" extentions. "psk_= key_exchange_modes"
>=C2=A0 =C2=A0 extension sets its mode to psk_dhe_ke.=C2=A0 The "ke= y_share" extention
>=C2=A0 =C2=A0 contains a KeyShareEntry structure that carries the ECDHE= parameters.
>

I think 'used the following' -> 'use the' and fir= st period should be
comma.


-Ilari

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114848302cc3c105413981b3-- From nobody Sun Nov 13 18:43:46 2016 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 D03F11294AE for ; Sun, 13 Nov 2016 18:43:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb7fCXEd4MF8 for ; Sun, 13 Nov 2016 18:43:43 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (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 0FA4A12945E for ; Sun, 13 Nov 2016 18:43:43 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id q124so87052779itd.1 for ; Sun, 13 Nov 2016 18:43:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=ScL3Pr1grp6GnZX+7pR3Vmbizj5EmE4t8uZYpI1X3O0=; b=UPUBjPlxlOCs5D4ZZUfgWDgUCq8GoPOTUcokiAnqqHSS+G2Fd93CfgFp5ZrplWibAu auhN+tRDphJuSd36lVjewKBzhEYcm2AZlLLbQS4FieWimq5LxdUaNrijhZGCzK20u9+X j+YenLHfsffkogitOOBU3aI3btuD9AmwqUPAmMkohoAt3xY2MxcqkhBR5u0tmZSHB3nK szQGo9f1CM7OVJcRprV5HlNKFiLETV4wXIXELHoxrhGpy98ALrFE4kE17XIlEar6hZr/ 55Et2HI4j8jBz2U9M6y3H+M4+FpaZL8eDjIU0O3aeV85hVnBcMCSWEQWc9P4NO2fIQYr AJXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=ScL3Pr1grp6GnZX+7pR3Vmbizj5EmE4t8uZYpI1X3O0=; b=UtmxSBl2i3GtOxH7XJhI25mD9pe8seWx5KDHbb+NhrBahxx+stprSPKNtU27gj6lzg WegFoU96SIMgzM/CmmKJwWnXqusLfClCquVIcIrdrwq3xtBHKBGpzUGAEhd0ktvTxvUK Y69tGrnJoZdlNLXGFQ1Ite+LahknxamLW4EERpcxVOHr5wGap+7VcCMyH5bk82mpdroX QUt1y2n2uNQEkwzX/ivHfM+LgJxi1EfZsl0T+6itcsC8YOUMH4R0vOU0NfjawrnSfcO4 51jciaWoOE7u+D1T4Ls6UDGJOaD6TV10N4KqQ+6kp5cxTQTn9dVouW1jjBGCPZJTs2h9 ZYXA== X-Gm-Message-State: ABUngvd/bVMhhIFxgs1vbc692oh4ptuiIkHA59r89/EYIRYxzBVgtqgvOxy0vRpRLcmu/6D5Dpgf/Y9mkQTdnw== X-Received: by 10.107.179.195 with SMTP id c186mr11293069iof.35.1479091422365; Sun, 13 Nov 2016 18:43:42 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.32.10 with HTTP; Sun, 13 Nov 2016 18:43:41 -0800 (PST) In-Reply-To: References: <20160527171935.11166.82258.idtracker@ietfa.amsl.com> <7a3597ae-92b8-23c8-b2c3-357f6fdb6792@bouncycastle.org> <6CE18F17-F8E0-4F4A-95A4-BE9B3A8250A2@sn3rd.com> <80bc8ae67e0ba0e2355b26bdbb34d1b6.squirrel@www.trepanning.net> <1478593476.2532.29.camel@redhat.com> <1478598547.2532.57.camel@redhat.com> From: Daniel Migault Date: Sun, 13 Nov 2016 21:43:41 -0500 X-Google-Sender-Auth: WjSuCLLfU88Y3Ie_Ljqt46oLghE Message-ID: To: Martin Thomson , Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a11484830d219d5054139ce17 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 02:43:45 -0000 --001a11484830d219d5054139ce17 Content-Type: text/plain; charset=UTF-8 I removed all these recommendations on 128/256 security. I believe this address this thread. I also believe a profile document would be useful and detail these details. Do you have any opinion about such a document ? Tank you for the feed backs! Yours, Daniel On Tue, Nov 8, 2016 at 7:24 PM, Martin Thomson wrote: > On 8 November 2016 at 21:08, Daniel Migault > wrote: > > TLS enable curve negotiation but not for code point. This makes > restrictions > > on code points hard to implement. As a result Endpoints MAY treat > > negotiation of key sizes smaller than the lower limits as a connection > error > > of type insufficient_security(71) for TLS 1.2 and TLS 1.3. > > I really had a hard time parsing this. You don't connect this to > Diffie-Hellman at all, but I think that is what you are talking about. > But if your point is that this is an ECDHE-specific draft, then you > don't need to say anything at all. > > nit "TLS enables" > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11484830d219d5054139ce17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I removed all these recommendations on 128/256 s= ecurity. I believe this address this thread.

I also believe a profi= le document would be useful and detail these details. Do you have any opini= on about such a document ?

Tank you for the feed backs!
Yours,
Daniel
On Tue, Nov 8, 2016 at 7:24 PM, Martin Thomson = <martin.thomson@gmail.com> wrote:
On 8 November 2016 at 21:08, Daniel Migault= <daniel.migault@ericsson= .com> wrote:
> TLS enable curve negotiation but not for code point. This makes restri= ctions
> on code points hard to implement.=C2=A0 As a result Endpoints MAY trea= t
> negotiation of key sizes smaller than the lower limits as a connection= error
> of type insufficient_security(71) for TLS 1.2 and TLS 1.3.

I really had a hard time parsing this.=C2=A0 You don't connect t= his to
Diffie-Hellman at all, but I think that is what you are talking about.
But if your point is that this is an ECDHE-specific draft, then you
don't need to say anything at all.

nit "TLS enables"

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a11484830d219d5054139ce17-- From nobody Sun Nov 13 18:48:28 2016 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A7BCD1293EE; Sun, 13 Nov 2016 18:48:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.37.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <147909170668.5623.2752300354221140401.idtracker@ietfa.amsl.com> Date: Sun, 13 Nov 2016 18:48:26 -0800 Archived-At: Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 02:48:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security of the IETF. Title : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer Security (TLS) Authors : John Mattsson Daniel Migault Filename : draft-ietf-tls-ecdhe-psk-aead-01.txt Pages : 7 Date : 2016-11-13 Abstract: This document defines several new cipher suites for the Transport Layer Security (TLS) protocol. The cipher suites are all based on the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key (ECDHE_PSK) key exchange together with the Authenticated Encryption with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK provides light and efficient authentication, ECDHE provides perfect forward secrecy, and AES-GCM and AES-CCM provides encryption and integrity protection. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Nov 13 18:53:17 2016 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 5EBC61296BA for ; Sun, 13 Nov 2016 18:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.202 X-Spam-Level: X-Spam-Status: No, score=-4.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 uRmLckSKVyL3 for ; Sun, 13 Nov 2016 18:53:13 -0800 (PST) Received: from usplmg20.ericsson.net (usplmg20.ericsson.net [198.24.6.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B9FF1295F0 for ; Sun, 13 Nov 2016 18:53:11 -0800 (PST) X-AuditID: c618062d-fbfff70000007e3f-39-58292b4f0e6d Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by (Symantec Mail Security) with SMTP id C7.EA.32319.F4B29285; Mon, 14 Nov 2016 04:11:14 +0100 (CET) Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0319.002; Sun, 13 Nov 2016 21:53:06 -0500 From: Daniel Migault To: "tls@ietf.org" Thread-Topic: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-01.txt Thread-Index: AQHSPiGVSCcLENtLk0W48SjC+t+ax6DXxwrQ Date: Mon, 14 Nov 2016 02:53:06 +0000 Message-ID: <2DD56D786E600F45AC6BDE7DA4E8A8C117FD4C70@eusaamb107.ericsson.se> References: <147909170679.5623.13090979149690132194.idtracker@ietfa.amsl.com> In-Reply-To: <147909170679.5623.13090979149690132194.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.12] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyuXSPn26QtmaEwa0mHYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8ejHTfaCZxIVj178Z25gnCLRxcjJISFgInHq316mLkYuDiGB 9YwSf//th3KWM0rMWT+JCaSKTcBIou1QPzuILSKgKLHjajeYLSwQIHHv7w6oeKDExf83WboY OYBsI4kpkxlBwiwCqhL/u3eygdi8Ar4Szd+esoDYQkD28Z//weKcAn4SU18/YgWxGQXEJL6f WgO2lllAXOLWk/lMEIcKSCzZc54ZwhaVePn4HyuErSQx5/U1ZpC1zAKaEut36UO0KkpM6X7I DrFWUOLkzCcsExhFZiGZOguhYxaSjllIOhYwsqxi5CgtLsjJTTcy2MQIDO5jEmy6OxjvT/c8 xCjAwajEw/uhXiNCiDWxrLgy9xCjBAezkghvr4pmhBBvSmJlVWpRfnxRaU5q8SFGaQ4WJXHe uNX3w4UE0hNLUrNTUwtSi2CyTBycUg2Mh/oc2hc+dJKR+16fv2XF+Ri5/AmL4rh+1JpVVH8p 36z2/3bOvHX6t2YmL9u6PGPTkux7U60WZzwN3tVgkMBvIrV68vGyN/q7WH/HFW/dWrj0WICt zqxX7Qd+3q9NmLmuRurPhfLSj2aVXPVnuw7e2Rrtd9LIP/5ZlhrvK9ui1V94bh6+PFWKV4ml OCPRUIu5qDgRAKtFNNJqAgAA Archived-At: Subject: [TLS] FW: New Version Notification for draft-ietf-tls-ecdhe-psk-aead-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 02:53:15 -0000 SGksIA0KDQpQbGVhc2UgZmluZCB0aGUgbGF0ZXN0IHZlcnNpb24gb2YgZHJhZnQtaWV0Zi10bHMt ZWNkaGUtcHNrLWFlYWQuIA0KDQpUaGlzIHZlcnNpb24gcmVtb3ZlcyB0aGUgdGV4dCBwcm92aWRp bmcgZ3VpZGFuY2Ugb24gaG93IHRvIGRlcGxveSAxMjgvMjU2IGJpdCBzZWN1cml0eS4gSW5zdGVh ZCB0aGlzIGhhcyBiZWVuIGxlZnQgdG8gdGhlICJnZW5lcmljIiBUTFMgc2VjdXJpdHkgcmVjb21t ZWRhdGlvbnMgZGVmaW5lZCBpbiBUTFMgMS4zLg0KDQpUaGlzIHZlcnNpb24gY2xhcmlmaWVzIHRo ZSBjb2RlIHBvaW50cyBhcmUgb25seSBmb3IgVExTIDEuMiBhcyB3ZWxsIGFzIGFuIGFkZGl0aW9u YWwgdGV4dCBkZWZpbmluZyBob3cgdG8gdXNlIHRoZXNlIGFsZ28gdXNpbmcgVExTIDEuMy4NCg0K VGhlIGRyYWZ0IGFsc28gcmVwbGFjZXMgVExTdmVyc2lvbiBieSBUTFMgdmVyc2lvbi4NCg0KV2Ug YmVsaWV2ZSB3ZSBhcmUgcmVhZHkgZm9yIFdHTEMuDQoNCllvdXJzLCANCkRhbmllbCAgDQoNCi0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg W21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogU3VuZGF5LCBOb3ZlbWJl ciAxMywgMjAxNiA5OjQ4IFBNDQpUbzogSm9obiBNYXR0c3NvbiA8am9obi5tYXR0c3NvbkBlcmlj c3Nvbi5jb20+OyBEYW5pZWwgTWlnYXVsdCA8ZGFuaWVsLm1pZ2F1bHRAZXJpY3Nzb24uY29tPjsg dGxzLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv ciBkcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC0wMS50eHQNCg0KDQpBIG5ldyB2ZXJzaW9u IG9mIEktRCwgZHJhZnQtaWV0Zi10bHMtZWNkaGUtcHNrLWFlYWQtMDEudHh0DQpoYXMgYmVlbiBz dWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IERhbmllbCBNaWdhdWx0IGFuZCBwb3N0ZWQgdG8gdGhl IElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFk DQpSZXZpc2lvbjoJMDENClRpdGxlOgkJRUNESEVfUFNLIHdpdGggQUVTLUdDTSBhbmQgQUVTLUND TSBDaXBoZXIgU3VpdGVzIGZvcsKgVHJhbnNwb3J0wqBMYXllcsKgU2VjdXJpdHnCoChUTFMpDQpE b2N1bWVudCBkYXRlOgkyMDE2LTExLTEzDQpHcm91cDoJCXRscw0KUGFnZXM6CQk3DQpVUkw6ICAg ICAgICAgICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt dGxzLWVjZGhlLXBzay1hZWFkLTAxLnR4dA0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdGxzLWVjZGhlLXBzay1hZWFkLw0KSHRtbGl6 ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXRscy1lY2Ro ZS1wc2stYWVhZC0wMQ0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2Rp ZmY/dXJsMj1kcmFmdC1pZXRmLXRscy1lY2RoZS1wc2stYWVhZC0wMQ0KDQpBYnN0cmFjdDoNCiAg IFRoaXMgZG9jdW1lbnQgZGVmaW5lcyBzZXZlcmFsIG5ldyBjaXBoZXIgc3VpdGVzIGZvciB0aGUg VHJhbnNwb3J0DQogICBMYXllciBTZWN1cml0eSAoVExTKSBwcm90b2NvbC4gIFRoZSBjaXBoZXIg c3VpdGVzIGFyZSBhbGwgYmFzZWQgb24NCiAgIHRoZSBFcGhlbWVyYWwgRWxsaXB0aWMgQ3VydmUg RGlmZmllLUhlbGxtYW4gd2l0aCBQcmUtU2hhcmVkIEtleQ0KICAgKEVDREhFX1BTSykga2V5IGV4 Y2hhbmdlIHRvZ2V0aGVyIHdpdGggdGhlIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbg0KICAgd2l0 aCBBc3NvY2lhdGVkIERhdGEgKEFFQUQpIGFsZ29yaXRobXMgQUVTLUdDTSBhbmQgQUVTLUNDTS4g IFBTSw0KICAgcHJvdmlkZXMgbGlnaHQgYW5kIGVmZmljaWVudCBhdXRoZW50aWNhdGlvbiwgRUNE SEUgcHJvdmlkZXMgcGVyZmVjdA0KICAgZm9yd2FyZCBzZWNyZWN5LCBhbmQgQUVTLUdDTSBhbmQg QUVTLUNDTSBwcm92aWRlcyBlbmNyeXB0aW9uIGFuZA0KICAgaW50ZWdyaXR5IHByb3RlY3Rpb24u DQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpQbGVhc2Ugbm90ZSB0aGF0IGl0IG1h eSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uIHVu dGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMu aWV0Zi5vcmcuDQoNClRoZSBJRVRGIFNlY3JldGFyaWF0DQoNCg== From nobody Sun Nov 13 18:54:31 2016 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 489AB1296B1; Sun, 13 Nov 2016 18:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 S4ITqqnb1IiH; Sun, 13 Nov 2016 18:54:27 -0800 (PST) Received: from gcc01-dm2-obe.outbound.protection.outlook.com (mail-dm2gcc01on0090.outbound.protection.outlook.com [23.103.201.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1D3C1295F0; Sun, 13 Nov 2016 18:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xf9nFAzTZyLt08Blf+25f4TBUcIVT4/pRSGQYmC8+qQ=; b=QrznycJ1nPCNxZk/oXK0Kr6ajQFQ/Fkes/DH29087k9phV4ryUCOHFR/t0/sjQfQ3ZTi0BNqT7HunLy79Iy+cMFSqzoT94pMw4bHZhNGXeq8daaeMHFTEF//5KXQhuATijGAd90F3w4xquBeqxY7nPOMfXyjXgAfkSNAdBjzeNU= Received: from DM5PR09MB1467.namprd09.prod.outlook.com (10.173.171.21) by DM5PR09MB1467.namprd09.prod.outlook.com (10.173.171.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.10; Mon, 14 Nov 2016 02:54:24 +0000 Received: from DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) by DM5PR09MB1467.namprd09.prod.outlook.com ([10.173.171.21]) with mapi id 15.01.0721.015; Mon, 14 Nov 2016 02:54:24 +0000 From: "Dang, Quynh (Fed)" To: Martin Thomson , "tls@ietf.org" Thread-Topic: [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5 Thread-Index: AQHSPe67hB6sb8v2EES9vmvjfbAsXqDXlqSAgAAv0JU= Date: Mon, 14 Nov 2016 02:54:23 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [2001:67c:370:128:65c1:ac62:aa5c:bc5b] x-microsoft-exchange-diagnostics: 1; DM5PR09MB1467; 7:R+9LPTJF77aW0idylmwUdjNml//Q91DwGrU8+HtwOI6H0s81NCaZSt6Ek7/z5+bV0Z2bYAgfnkqIAhHtX0ucJAxTdAtsLtxym7BwZ71PKEotQCrwMFLdGeJ0fHiQ6jYVmMpE5wghun1c8ULrLdVRIxfghTzJp8hTyepjaIA9XD2OwUo+4Yo3T07HbWTlW7JHRkMHOymgdL7TBqRfJmAQbfugBe8WFyutuWeG9bafoFphFW34jxmNPlSQC3Ts1Cmmm5KhcK2bbdT91SA/9QIRKMKpB28ILlnl+vHuoMQoP0oMxCHgS7PBnMH+ESm1xpIvU8iBJiTDrgD+sX99HOsn+A0fgTWdnatDM0MTECv0x6s= x-ms-office365-filtering-correlation-id: 1489a721-5f84-42a0-96fe-08d40c398a7b x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR09MB1467; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(65766998875637)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060314)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6061309); SRVR:DM5PR09MB1467; BCL:0; PCL:0; RULEID:; SRVR:DM5PR09MB1467; x-forefront-prvs: 0126A32F74 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(336003)(199003)(24454002)(377454003)(189002)(76576001)(6606003)(87936001)(586003)(102836003)(2900100001)(81156014)(68736007)(81166006)(33656002)(6116002)(92566002)(54356999)(5660300001)(9686002)(76176999)(101416001)(77096005)(7696004)(50986999)(8936002)(4326007)(229853002)(2906002)(122556002)(2950100002)(106356001)(99286002)(106116001)(105586002)(3900700001)(19627405001)(8676002)(2501003)(3280700002)(74316002)(7846002)(189998001)(7906003)(7736002)(86362001)(3660700001)(5001770100001)(97736004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR09MB1467; H:DM5PR09MB1467.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM5PR09MB14673CCBCDC107D5912F8669F3BC0DM5PR09MB1467namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Nov 2016 02:54:23.9955 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR09MB1467 Archived-At: Cc: "cfrg@ietf.org" Subject: Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 02:54:29 -0000 --_000_DM5PR09MB14673CCBCDC107D5912F8669F3BC0DM5PR09MB1467namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Martin, "very conservative" ? No. 1/2^32 and 1/2^57 are practically the same; they = are both practically zero. By your argument, if somebody wants to be more "conservative" and uses the = margin of 1/2^75 instead, then he/she would need to stop using GCM then. Rekeying too often than needed would just create more room for issues for t= he connection/session without gaining any additional practical security at = all. Quynh. ________________________________ From: Martin Thomson Sent: Sunday, November 13, 2016 6:54 PM To: Dang, Quynh (Fed) Cc: ekr@rtfm.com; tls@ietf.org; cfrg@ietf.org Subject: Re: [Cfrg] Data limit to achieve Indifferentiability for ciphertex= t with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5 These are intentionally very conservative. Having implemented this, I find it OK. The text cites its sources. Reading those sources corrects any misapprehension. The key point here is that we want to ensure that the initial - maybe uninformed - inferences need to be for the safe thing. We don't want to have the situation where we have looser text and that leads to mistakes. For instance, someone could deploy code that assumes a certain "average" record size based on a particular deployment and hence a larger limit. If the deployment characteristics change without the code changing we potentially have an issue. You really need to demonstrate that there is harm with the current text. if rekeying happens on that timescale (which is still very large), that's not harmful. I'm concerned that we aren't going to rekey often enough. I don't agree that it will create any negative perception of GCM. On 14 November 2016 at 05:48, Dang, Quynh (Fed) wrote= : > Hi Eric and all, > > > Regardless of the actual record size, each 128-bit block encryption is > performed with a unique 128-bit counter which is formed by the 96-bit IV = and > the 32-bit counter_block value called CB in NIST SP 800-38D under a given > key as long as the number of encrypted records is not more than 2^64. > > Assuming a user would like to limit the probability of a collision among > 128-bit ciphertext-blocks under 1/2^32, the data limit of the ciphertext = ( > or plaintext) is 2^(96/2) (=3D 2^48) 128-bit blocks which is 2^64 bytes. > > Reading the 2nd paragraph of section 5.5, a user might feel that he/she > needs to rekey a lot more quicker than he/she needs. Putting an > unnecessarily low data limit of 2^24.5 full-size records (2^38.5 bytes) a= lso > creates an incorrect negative impression (in my opinion) about GCM. > > I would like to request the working group to consider to revise the text. > > Regards, > Quynh. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > https://www.irtf.org/mailman/listinfo/cfrg > --_000_DM5PR09MB14673CCBCDC107D5912F8669F3BC0DM5PR09MB1467namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Martin,


"very conservative" ? No. 1/2^32 and 1/2^57 are practically th= e same; they are both practically zero.


By your argument, if somebody wants to be more "conservat= ive" and uses the margin of 1/2^75 instead, then he/she would nee= d to stop using GCM then. 


Rekeying too often than needed would just create more room for issues fo= r the connection/session without gaining any additional practical = ;security at all. 


Quynh. 



From: Martin Thomson <= martin.thomson@gmail.com>
Sent: Sunday, November 13, 2016 6:54 PM
To: Dang, Quynh (Fed)
Cc: ekr@rtfm.com; tls@ietf.org; cfrg@ietf.org
Subject: Re: [Cfrg] Data limit to achieve Indifferentiability for ci= phertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5
 
These are intentionally very conservative.  H= aving implemented this, I
find it OK.  The text cites its sources.  Reading those sources corrects any misapprehension.

The key point here is that we want to ensure that the initial - maybe
uninformed - inferences need to be for the safe thing.  We don't want<= br> to have the situation where we have looser text and that leads to
mistakes.

For instance, someone could deploy code that assumes a certain
"average" record size based on a particular deployment and hence = a
larger limit.  If the deployment characteristics change without the code changing we potentially have an issue.

You really need to demonstrate that there is harm with the current
text.  if rekeying happens on that timescale (which is still very
large), that's not harmful.  I'm concerned that we aren't going to
rekey often enough.  I don't agree that it will create any negative perception of GCM.

On 14 November 2016 at 05:48, Dang, Quynh (Fed) <quynh.dang@nist.gov>= wrote:
> Hi Eric and all,
>
>
> Regardless of the actual record size, each 128-bit block encryption is=
> performed with a unique 128-bit counter which is formed by the 96-bit = IV and
> the 32-bit counter_block value called CB in NIST SP 800-38D under a gi= ven
> key as long as the number of encrypted records is not more than 2^64.<= br> >
> Assuming a user would like to limit the probability of a collision amo= ng
> 128-bit ciphertext-blocks under 1/2^32, the data limit of the cipherte= xt (
> or plaintext) is 2^(96/2) (=3D 2^48) 128-bit blocks which is 2^64 byte= s.
>
> Reading the 2nd paragraph of section 5.5, a user might feel that he/sh= e
> needs to rekey a lot more quicker than he/she needs. Putting an
> unnecessarily low data limit of 2^24.5 full-size records (2^38.5 bytes= ) also
> creates an incorrect negative impression (in my opinion) about GCM. >
> I would like to request the working group to consider to revise the te= xt.
>
> Regards,
> Quynh.
>
>
> _______________________________________________
> Cfrg mailing list
> Cfrg@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
--_000_DM5PR09MB14673CCBCDC107D5912F8669F3BC0DM5PR09MB1467namp_-- From nobody Mon Nov 14 04:22:25 2016 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 C65CB12959D for ; Mon, 14 Nov 2016 04:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 ZXj6sMURiP1G for ; Mon, 14 Nov 2016 04:22:19 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 86315129540 for ; Mon, 14 Nov 2016 04:22:19 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F3596496C02; Mon, 14 Nov 2016 12:22:14 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id D3A5316C859; Mon, 14 Nov 2016 12:22:14 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479126134; bh=sD5sR3Z2chNxrPCz7ThvEUj1mtr09Ja0VQSj4DZDBT8=; l=8692; h=From:To:CC:Date:References:In-Reply-To:From; b=Tu8bETkOwTkP/bACxLxlcUeITMlDgEsWdBEqbQ72O83UDcadGLXLuX9nXa54LWdIJ ssMIraP77fZ/9cFgSzs9iM280nOj/tTEDR2+3Def1VcLXzSox00Ln2AmWSCsielSwx oIXKyAEKGZspRcyXEjcjCBAazNy3pdhxwTT/k2DI= Received: from email.msg.corp.akamai.com (ustx2ex-cas5.msg.corp.akamai.com [172.27.25.34]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id D0A691E099; Mon, 14 Nov 2016 12:22:14 +0000 (GMT) Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com (172.27.27.104) by ustx2ex-dag1mb2.msg.corp.akamai.com (172.27.27.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 14 Nov 2016 06:22:14 -0600 Received: from USTX2EX-DAG1MB4.msg.corp.akamai.com ([172.27.6.134]) by ustx2ex-dag1mb4.msg.corp.akamai.com ([172.27.6.134]) with mapi id 15.00.1178.000; Mon, 14 Nov 2016 06:22:14 -0600 From: "Kaduk, Ben" To: Eric Rescorla Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 Thread-Index: AQHSL/2/xyFB68/ah0yZwHLj0TFHDaDXsoAAgACDboCAAE2LgA== Date: Mon, 14 Nov 2016 12:22:13 +0000 Message-ID: References: <13C3DBCF-2609-4560-A194-1FA422BE7EEE@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.113.95] Content-Type: text/plain; charset="utf-8" Content-ID: <173005E5ACD1404EA9A5AF41CD0C83AD@akamai.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 12:22:24 -0000 VW5mb3J0dW5hdGVseSwgT3V0bG9vayBzZWVtcyB0byBiZSBpbmNhcGFibGUgb2YgcHJvcGVybHkg cXVvdGluZyBhIG1lc3NhZ2UgZm9yIGlubGluZSByZXBsaWVzLCBzbyBJIHdpbGwgaGF2ZSB0byB0 b3AtcG9zdCB3aXRoIHRoZSByZWxldmFudCBiaXRzLg0KDQpJ4oCZbGwgdHJ5IHRvIHB1dCB0b2dl dGhlciBzb21lIHRleHQgb24gc2lkZS1jaGFubmVsIHJlc2lzdGFuY2UgYWxvbmcgd2l0aCBteSBw dWxsIHJlcXVlc3QgZm9yIGVkaXRvcmlhbCBjaGFuZ2VzLg0KDQpXaXRoIHJlc3BlY3QgdG8gcHNr X2tleV9leGNoYW5nZV9tb2RlcywgUHJlU2hhcmVkS2V5IGFuZCBLZXlTaGFyZSBhcmUgZW5vdWdo IGZvciB0aGUgZXhpc3RpbmcgbW9kZXMsIGJ1dCBteSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IHRo ZSBwbGFuIHdpdGggc3BsaXR0aW5nIHRoZSBtb2RlcyBvdXQgdGhpcyB3YXkgd2FzIHRvIGFsbG93 IGFkZGluZyBuZXcgbW9kZXMgaW4gbGF0ZXIgZG9jdW1lbnRzLCBpbmNsdWRpbmcgUFNLIGZvciBz ZXJ2ZXIgYXV0aGVudGljYXRpb24uICBDYW4gd2UgZ3VhcmFudGVlIHRoYXQgZm9yIGFsbCBmdXR1 cmUgbW9kZXMgd2UgbWlnaHQgYWRkLCB0aGVyZSB3aWxsIGJlIHNvbWUgb3RoZXIgZXh0ZW5zaW9u IHRoYXQgaW5kaWNhdGVzIHdoYXQgd2FzIHBpY2tlZD8gIChJIGd1ZXNzIHdlIGNhbiBwcm9iYWJs eSBhcnJhbmdlIGZvciB0aGF0IHRvIGhhcHBlbiB3aXRoIGhvdyB3ZSBzcGVjaWZ5IHRoZSBuZXcg bW9kZXMsIHNvIGl04oCZcyBub3QgYWN0dWFsbHkgYSBiaWcgZGVhbCwgYnV0IG1pZ2h0IG9yIG1p Z2h0IG5vdCBtYWtlIHRoaW5ncyBtb3JlIGF3a3dhcmQgaW4gdGhlIGZ1dHVyZS4pDQoNClRoZSBw cm9ibGVtYXRpYyB0ZXh0IGFib3V0IGNpcGhlcnRleHQgbGVuZ3RoL2V4cGFuc2lvbiBmb3IgdGFn IGFuZCBvdGhlciB0aGluZ3Mgd2FzIGluIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgVExTQ2lwaGVy dGV4dCDigJhsZW5ndGjigJkgZmllbGQsIHdoaWNoIHNheXM6DQoNCiAgIGxlbmd0aCAgVGhlIGxl bmd0aCAoaW4gYnl0ZXMpIG9mIHRoZSBmb2xsb3dpbmcNCiAgICAgIFRMU0NpcGhlcnRleHQuZnJh Z21lbnQsIHdoaWNoIGlzIHRoZSBzdW0gb2YgdGhlIGxlbmd0aHMgb2YgdGhlDQogICAgICBjb250 ZW50IGFuZCB0aGUgcGFkZGluZywgcGx1cyBvbmUgZm9yIHRoZSBpbm5lciBjb250ZW50IHR5cGUu ICBUaGUNCiAgICAgIGxlbmd0aCBNVVNUIE5PVCBleGNlZWQgMl4xNCArIDI1Ni4gIEFuIGVuZHBv aW50IHRoYXQgcmVjZWl2ZXMgYQ0KICAgICAgcmVjb3JkIHRoYXQgZXhjZWVkcyB0aGlzIGxlbmd0 aCBNVVNUIHRlcm1pbmF0ZSB0aGUgY29ubmVjdGlvbiB3aXRoDQogICAgICBhICJyZWNvcmRfb3Zl cmZsb3ciIGFsZXJ0Lg0KDQooVGhlcmUgaXMgbm8gVExTQ2lwaGVydGV4dC5mcmFnbWVudCBmaWVs ZC4pICBBc3N1bWluZyBpdOKAmXMgdGFsa2luZyBhYm91dCB0aGUgbGVuZ3RoIG9mIHRoZSDigJxv cGFxdWUgZW5jcnlwdGVkX3JlY29yZFtsZW5ndGhd4oCdIG1lbWJlciAod2hpY2ggc2VlbXMgb2J2 aW91cyksIEkgZG8gbm90IHNlZSBob3cgdGhlIGxlbmd0aCBpcyB0aGUgc3VtIG9mIHRoZSBsZW5n dGggb2YgdGhlIChwbGFpbnRleHQpIGNvbnRlbnQgYW5kIHBhZGRpbmcgYW5kIGNvbnRlbnQtdHlw ZSBvY3RldCwgc2luY2UgdGhlIEFFQUQtZW5jcnlwdGlvbiBpcyBzdXBwb3NlZCB0byBhZGQgc29t ZSBhbW91bnQgb2YgZXhwYW5zaW9uLiAgUHJvYmFibHkgdGhlIGFuc3dlciBpcyB0byBqdXN0IHJl bW92ZSBhbnkgZGlzY3Vzc2lvbiBhYm91dCB3aGF0IHRoZSBsZW5ndGggcmVwcmVzZW50cywgc2lu Y2UgaXQgaXMgbm90IHJlYWxseSBoZWxwaW5nIGFueXRoaW5nOyB0aGUgc3BlY2lmaWNhdGlvbiBm b3IgdGhlIEFFQUQgaW4gdXNlIHdpbGwgc3BlY2lmeSB0aGUgY2lwaGVydGV4dCBsZW5ndGguDQoN Ck9uIDExLzE0LzE2LCAxMDo0NCwgIkVyaWMgUmVzY29ybGEiIDxla3JAcnRmbS5jb20+IHdyb3Rl Og0KDQogICAgDQogICAgDQogICAgT24gTW9uLCBOb3YgMTQsIDIwMTYgYXQgODo1NCBBTSwgS2Fk dWssIEJlbiANCiAgICA8YmthZHVrQGFrYW1haS5jb20+IHdyb3RlOg0KICAgIA0KICAgIEkgaGF2 ZSByZXZpZXdlZCB0aGlzIGRvY3VtZW50IGFuZCBoYXZlIGEgZmV3IG1pbm9yIGNvbW1lbnRzLiAg SSBhbHNvIGhhdmUgbWFueSBlZGl0b3JpYWwgbm90ZXMgdGhhdCBjYW4gYmUgYWRkcmVzc2VkIG91 dCBvZiBiYW5kLg0KICAgIA0KICAgIEluIHRoZSBhYnN0cmFjdCBhbmQgaW50cm9kdWN0aW9uLCB3 ZSBoYXZlIHRleHQgYWJvdXQgdGhlIHByb3BlcnRpZXMgdGhhdCBUTFMgaXMgZXhwZWN0ZWQgdG8g cHJvdmlkZSwgbGlrZSBjb25maWRlbnRpYWxpdHksIGF1dGhlbnRpY2F0aW9uLCBldGMuICBEbyB3 ZSB3YW50IHRvIHNheSBhbnl0aGluZyBhYm91dCBhdm9pZGluZyBzaWRlIGNoYW5uZWxzIHRoYXQg bWlnaHQgbGVhayBpbmZvcm1hdGlvbiBhYm91dCB0aGUgZGF0YSBiZWluZyBleGNoYW5nZWQ/IA0K ICAgICBJIGtub3cgdGhhdCB3ZSBhcmUgbm90IDEwMCUgY29uZmlkZW50IGF0IHdoYXQgZXhhY3Rs eSB3ZSBjdXJyZW50bHkgYWNoaWV2ZSBpbiB0aGlzIGFyZWEsIGJ1dCBzaW5jZSB3ZSBoYXZlIG1l Y2hhbmlzbXMgdGhhdCBhdHRlbXB0IHRvIGFjaGlldmUgaXQsIG1heWJlIGl0IGlzIHdvcnRoIG1l bnRpb25pbmcuICAoSW4gYSBzaW1pbGFyIHZlaW4sIGFzIGRhdmlkYmVuIHJlbWluZGVkIG1lIHJl Y2VudGx5LCBhbiBhdHRhY2tlciDigJx3aG8gaGFzIGNvbXBsZXRlDQogICAgIGNvbnRyb2wgb2Yg dGhlIG5ldHdvcmvigJ0sIGFzIGlzIG91ciBzdGF0ZWQgYWR2ZXJzYXJ5LCBjYW4gZG8gdGhpbmdz IGxpa2UgdHJpY2tsZSBwYWNrZXRzIGluIG9uZSBieSBvbmUgYW5kIHRyeSB0byBzZWUsIGUuZy4s IHdoZXJlIHRoZSBlbmQgb2YgZWFybHkgZGF0YSBpcyBhbmQgcXVlcnkgaGFuZHNoYWtlIHN0YXRl LiAgU28gc29tZSB0aGluZ3MgbWF5IG5vdCBiZSBhdm9pZGFibGUuKQ0KICAgIA0KICAgIA0KICAg IA0KICAgIA0KICAgIEknZCBiZSBpbnRlcmVzdGVkIGluIHNlZWluZyBhIFBSIGluIHRoaXMgYXJl YS4NCiAgICANCiAgICANCiAgICANCiAgICANCiAgICANCiAgICBJbiBzZWN0aW9uIDQuMi41LjEg d2UgdGFsayBhYm91dCBob3cgZm9yIEZGREggcGVlcnMgU0hPVUxEIHZhbGlkYXRlIGVhY2ggb3Ro ZXLigJlzIHB1YmxpYyBrZXkgWSBieSBlbnN1cmluZyB0aGF0IDEgPCBZIDwgcC0xLCB3aGljaCBp cyBzdXBwb3NlZCB0byBlbnN1cmUgdGhhdCB0aGUgcGVlciBpcyB3ZWxsLWJlaGF2ZWQgYW5kIGlz buKAmXQgZm9yY2luZyB0aGUgbG9jYWwgc3lzdGVtIGludG8gYSBzbWFsbCBzdWJncm91cC4gIFNv bWVob3cgSSB0aG91Z2h0DQogICAgIHRoYXQgYWRkaXRpb25hbCBjaGVja3Mgd2VyZSBuZWVkZWQg dG8gYXZvaWQgYmVpbmcgZm9yY2VkIGludG8gYSBzbWFsbCBzdWJncm91cCwgYnV0IEkgZ3Vlc3Mg dGhhdCBkZXBlbmRzIG9uIHdoYXQgZ3JvdXAgaXTigJlzIGluLCBhbmQgSSBkaWRu4oCZdCBwdWxs IHVwIHRoZSBSRkMgNzkxOSByZWZlcmVuY2Ugd2hlbiBJIHdhcyByZWFkaW5nIHRoaXMgZG9jdW1l bnQuDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgVGhlc2UgYXJlIHRoZSByZWNvbW1lbmRh dGlvbnMgaW4gNzkxOSwgSSBiZWxpZXZlDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgSW4g c2VjdGlvbiA0LjIuNywgd2Ugbm90ZSB0aGF0IHRoZSBzZXJ2ZXIgTVVTVCBOT1Qgc2VuZCB0aGUg 4oCccHNrX2tleV9leGNoYW5nZV9tb2Rlc+KAnSBleHRlbnNpb24sIHdpdGggdGhlIGltcGxpY2F0 aW9uIHRoYXQgdGhlIGNsaWVudCBtdXN0IG9ic2VydmVyIHRoZSB0eXBlcyBvZiBoYW5kc2hha2Ug bWVzc2FnZXMgdGhhdCBhcmUgc3Vic2VxdWVudGx5IHJlY2VpdmVkIGluIG9yZGVyIHRvIGRldGVy bWluZSB3aGF0IHRoZSBzZXJ2ZXIgc2VsZWN0ZWQuIA0KICAgICBJIHRoaW5rIHRoYXQgd2UgaGFk IHRhbGtlZCBhYm91dCB0aGlzIGFscmVhZHkgc29tZSB0aW1lIGFnbywgYnV0IGp1c3Qgd2FudGVk IHRvIGNvbmZpcm0gdGhhdCB3ZSBhcmUgb2theSB3aXRoIGluY3JlYXNpbmcgdGhlIHNpemUgb2Yg dGhlIGNsaWVudCBzdGF0ZSBtYWNoaW5lIGluIHRoaXMgbWFubmVyLg0KICAgIA0KICAgIA0KICAg IA0KICAgIA0KICAgIEl0J3Mgbm90IHN1YnNlcXVlbnQgbWVzc2FnZXMuIFlvdSBkZXRlcm1pbmUg aXQgZnJvbSB0aGUgUHJlU2hhcmVkS2V5IGFuZCBLZXlTaGFyZSBleHRlbnNpb25zLg0KICAgIA0K ICAgIA0KICAgIA0KICAgIA0KICAgIEluIHNlY3Rpb24gNC41LjEgd2Ugbm90ZSB0aGF0IHdoZW4g Y2xpZW50IGF1dGggaXMgbm90IHVzZWQsIHNlcnZlcnMgTUFZIGNvbXB1dGUgdGhlIHJlbWFpbmRl ciBvZiB0aGUgY2xpZW50LXNlbnQgbWVzc2FnZXMgZm9yIHRoZSB0cmFuc2NyaXB0IHNvIGFzIHRv IGlzc3VlIGEgTmV3U2Vzc2lvblRpY2tldCBpbW1lZGlhdGVseSBhZnRlciB0aGUgc2VydmVyIEZp bmlzaGVkLiAgRG8gd2Ugd2FudCB0byBzYXkgYW55dGhpbmcgYWJvdXQgd2h5IGEgc2VydmVyDQog ICAgIG1pZ2h0IHdpc2ggdG8gZG8gc28/DQogICAgDQogICAgDQogICAgDQogICAgDQogICAgSSB0 aGluayBJIHdvdWxkIHJhdGhlciBub3QuDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQog ICAgVGhlIGNvdmVyYWdlIG9mIHJlY29yZCBwYXlsb2FkIHByb3RlY3Rpb24gKGFyb3VuZCBzZWN0 aW9uIDUuMikgc2VlbXMgdG8gbm90IGFsd2F5cyBtYWtlIGNhcmVmdWwgZGlzdGluY3Rpb24gYmV0 d2VlbiBUTFNQbGFpbnRleHQsIFRMU0NpcGhlcnRleHQsIFRMU0lubmVyUGxhaW50ZXh0LCBhbmQg dGhlIGZpZWxkcyB0aGVyZWluLiAgSW4gc29tZSBzZW5zZSB0aGlzIGlzIGVkaXRvcmlhbCwgYnV0 IHRoZXJlIHdlcmUgYSBsb3Qgb2YgcGxhY2VzIHRoYXQNCiAgICAgSSBmbGFnZ2VkLCBzbyBJIHdh bnRlZCB0byBjYWxsIGl0IG91dCB0byB0aGUgYnJvYWRlciBhdWRpZW5jZSBhbmQgZ2V0IG1vcmUg ZXllcyBvbiBpdC4gIEkgYWxzbyBkaWRu4oCZdCBmaW5kIGEgZGVzY3JpcHRpb24gb2Ygd2hlcmUg dGhlIGxlbmd0aCBvZiB0aGUgQUVBRCBhdXRoZW50aWNhdGlvbiB0YWcgZ2V0cyBpbmNsdWRlZCBp bnRvIGEgbGVuZ3RoIGZpZWxkIGZvciB0aGUgY2lwaGVydGV4dC4NCiAgICANCiAgICANCiAgICAN CiAgICANCiAgICBJJ20gbm90IGZvbGxvd2luZyB0aGlzIHBvaW50LiBUaGUgd2F5IHRvIHRoaW5r IGFib3V0IHRoaXMgaXMgdGhhdCB0aGUgY2lwaGVydGV4dCBpcyBhIHNwZWNpZmljIHNpemUuIFRo YXQgbWF5IGJlIGVuY3J5cHRpb24gKyBhdXRoIHRhZyBvciBub3QgKGl0J3MgcG9zc2libGUgdG8g ZGVzaWduIGFuIEFFQUQgYWxnb3JpdGhtIHRoYXQgZG9lc24ndCBoYXZlIGEgc2VwYXJhdGUgYXV0 aCB0YWcpLg0KICAgIA0KICAgIA0KICAgIC1Fa3INCiAgICANCiAgICANCiAgICANCiAgICBBdCB0 aGUgZW5kIG9mIHNlY3Rpb24gNi4xIHdlIGhhdmUgdGhpcyBsaXR0bGUgbm90ZSB0aGF0IOKAnGl0 IGlzIGFzc3VtZWQgdGhhdCBjbG9zaW5nIGEgY29ubmVjdGlvbiByZWxpYWJseSBkZWxpdmVycyBw ZW5kaW5nIGRhdGEgYmVmb3JlIGRlc3Ryb3lpbmcgdGhlIHRyYW5zcG9ydOKAnSwgd2hpY2gsIGlm IEkgcmVtZW1iZXIgY29ycmVjdGx5IHByZXZpb3VzIGRpc2N1c3Npb24gb24gdGhpcyBsaXN0LCBp cyBub3QgYWN0dWFsbHkgdHJ1ZSBmb3IgbGludXguIA0KICAgICBJdCBpcyBwZXJoYXBzIHByb2Js ZW1hdGljIHRvIGhhdmUgYW4gYXNzdW1wdGlvbiB0aGF0IHdlIGtub3cgaXMgbm90IGdvaW5nIHRv IGJlIGhlbGQgZm9yIGEgbGFyZ2UgcHJvcG9ydGlvbiBvZiBpbXBsZW1lbnRhdGlvbnMuDQogICAg DQogICAgLUJlbg0KICAgIA0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgVExTIG1haWxpbmcgbGlzdA0KICAgIFRMU0BpZXRmLm9yZw0KICAg IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzIDxodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWls bWFuX2xpc3RpbmZvX3RscyZkPURnTUZhUSZjPTk2WmJaWmNhTUY0dzBGNGpwTjZMWmcmcj1zc3NE TGtlRUVCV05JWG1Uc2RwdzhUWjN0QUp4LUpvYjRwMXVuYzdyT2hNJm09NFcta3JNR0hleW9Vc3FQ TTZ1UkNOeGtqYUp6Tzl0UWNkYTROMlNURmt6ZyZzPXB4Z1RHMjh0SU4yVlZ3WUd6WEc1ZkkyXzFT aUpFV2ZQa0NCSzdScFZtb00mZT0+DQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQogICAg DQogICAgDQogICAgDQogICAgDQoNCg== From nobody Mon Nov 14 04:58:48 2016 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 52BEC129522 for ; Mon, 14 Nov 2016 04:58:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.419 X-Spam-Level: X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 vttxrLfJU3_d for ; Mon, 14 Nov 2016 04:58:37 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC61C12940A for ; Mon, 14 Nov 2016 04:58:37 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6FBEDF806B; Mon, 14 Nov 2016 12:58:37 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.106]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAECwZK8002174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 14 Nov 2016 07:58:36 -0500 Message-ID: <1479128315.2624.62.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Mon, 14 Nov 2016 13:58:35 +0100 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Mon, 14 Nov 2016 12:58:37 +0000 (UTC) Archived-At: Cc: Hannes Tschofenig Subject: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 12:58:41 -0000 Hi,  For draftâ€mavrogiannopoulos­â€dtls­â€cid­â€00 and we needed to extend the DTLS un-authenticated part of the DTLS record header with an additional field. That works well if this is the only draft ever extending the DTLS record header. If not, modification order would be undefined. Would it make sense to introduce an extension header for DTLS 1.3 in the lines of the IPv6 extension headers? That would allow TLS extension negotiation to add more items on the un-authenticated header, and potentially also remove redundant headers.  What do you think? regards, Nikos From nobody Mon Nov 14 05:36:44 2016 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 9C1A01296F9 for ; Mon, 14 Nov 2016 05:36:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 qOdJzfQTCc6b for ; Mon, 14 Nov 2016 05:36:41 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987101296FA for ; Mon, 14 Nov 2016 05:36:39 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 6A47CB3E52E49; Mon, 14 Nov 2016 13:36:35 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAEDaafX014196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Nov 2016 13:36:37 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uAEDaaqZ016025 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 14 Nov 2016 14:36:36 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.241]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Mon, 14 Nov 2016 14:36:36 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Nikos Mavrogiannopoulos , "tls@ietf.org" Thread-Topic: [ALU] [TLS] extending the un-authenticated DTLS header Thread-Index: AQHSPnbnU+YENl7RkU2s4xocSassXqDYaoiA Date: Mon, 14 Nov 2016 13:36:35 +0000 Message-ID: References: <1479128315.2624.62.camel@redhat.com> In-Reply-To: <1479128315.2624.62.camel@redhat.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Hannes Tschofenig Subject: Re: [TLS] [ALU] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 13:36:42 -0000 SGkgTmlrb3MsDQoNCk9uIDE0LzExLzIwMTYgMTI6NTgsICJUTFMgb24gYmVoYWxmIG9mIE5pa29z IE1hdnJvZ2lhbm5vcG91bG9zIg0KPHRscy1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBu bWF2QHJlZGhhdC5jb20+IHdyb3RlOg0KPkhpLA0KPiBGb3IgZHJhZnQtbWF2cm9naWFubm9wb3Vs b3OhqS1kdGxzoaktY2lkoaktMDAgYW5kIHdlIG5lZWRlZCB0byBleHRlbmQgdGhlDQo+RFRMUyB1 bi1hdXRoZW50aWNhdGVkIHBhcnQgb2YgdGhlIERUTFMgcmVjb3JkIGhlYWRlciB3aXRoIGFuIGFk ZGl0aW9uYWwNCj5maWVsZC4gVGhhdCB3b3JrcyB3ZWxsIGlmIHRoaXMgaXMgdGhlIG9ubHkgZHJh ZnQgZXZlciBleHRlbmRpbmcgdGhlDQo+RFRMUyByZWNvcmQgaGVhZGVyLiBJZiBub3QsIG1vZGlm aWNhdGlvbiBvcmRlciB3b3VsZCBiZSB1bmRlZmluZWQuDQo+DQo+V291bGQgaXQgbWFrZSBzZW5z ZSB0byBpbnRyb2R1Y2UgYW4gZXh0ZW5zaW9uIGhlYWRlciBmb3IgRFRMUyAxLjMgaW4NCj50aGUg bGluZXMgb2YgdGhlIElQdjYgZXh0ZW5zaW9uIGhlYWRlcnM/IFRoYXQgd291bGQgYWxsb3cgVExT IGV4dGVuc2lvbg0KPm5lZ290aWF0aW9uIHRvIGFkZCBtb3JlIGl0ZW1zIG9uIHRoZSB1bi1hdXRo ZW50aWNhdGVkIGhlYWRlciwgYW5kDQo+cG90ZW50aWFsbHkgYWxzbyByZW1vdmUgcmVkdW5kYW50 IGhlYWRlcnMuDQo+DQo+V2hhdCBkbyB5b3UgdGhpbms/DQoNCkluIERUTFMgMS4zIHdlIGNvdWxk IHByb2JhYmx5IHJlLXB1cnBvc2UgdGhlIHZlcnNpb24gZmllbGQgdG8gc2lnbmlmeQ0KImhlYWRl ciB2ZXJzaW9uIiBpbnN0ZWFkPw0KDQo= From nobody Mon Nov 14 15:20:34 2016 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 9257B12941C for ; Mon, 14 Nov 2016 15:20:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 rLCTdM5fThM6 for ; Mon, 14 Nov 2016 15:20:31 -0800 (PST) Received: from mail-it0-x22c.google.com (mail-it0-x22c.google.com [IPv6:2607:f8b0:4001:c0b::22c]) (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 C11221294AB for ; Mon, 14 Nov 2016 15:20:30 -0800 (PST) Received: by mail-it0-x22c.google.com with SMTP id q124so133213357itd.1 for ; Mon, 14 Nov 2016 15:20:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=bYHxUD5p9NBbT3LE37sE5mqvZywQUaMMF50/TMrZc5g=; b=f1a85wv40ou0iFgTH6yH2Az7Pm1D9Q96IC9PiaFbjRqm71+t0eePaUKFS0Ak+bWksm 08aMKdjjbdw1O7hoWZpkDpE7JP0ZvqObBHVppjKJi72sSry5VPFY5eb84tZ8WDJt8+RL 9Tsosvre2mbC2E4HCV++UhUn6ITEsQFzN9hWc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=bYHxUD5p9NBbT3LE37sE5mqvZywQUaMMF50/TMrZc5g=; b=YiZhetYNTXA6CZDZUsZr+K/R+KkvzWQVfJt2VuxmV/HZcDSYe2jWD6ALSC0WtqwpTM Z0VlZd6jxkDWlxvN9Fx1vQ2UboVvD/iGbZ4pdvDLne+DBaIvuegxBerzOTRSY1RKfYWN AKLC+7xJNEm1lwTNkxcQSQhjCoR2YFhmRj3Tk6S+mcPivQlljmxee8HsEiuc2yX/icGI WsYc/hckYc1++87txBZPZgbcHWsUzbfNn8qgR+1nxu3q9vs3YU3R3Mcsh+hbDmkP3vPt yiNlmF3iEblHt6OgfhK/jhRTFnH+lZM3pZ4k/3k6pExGpWLEgVhgYpUWfjVQSDsGqiYl wH4w== X-Gm-Message-State: ABUngvcaz8fwhTSJUFI+4AO4gFvmVgvf0HZY5cYkiEXC5+b+xi9gEpcijt9Z5fc4GYnOog== X-Received: by 10.157.7.38 with SMTP id 35mr7562136ote.87.1479165629896; Mon, 14 Nov 2016 15:20:29 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:cd02:ce70:3008:8583? ([2001:67c:370:144:cd02:ce70:3008:8583]) by smtp.gmail.com with ESMTPSA id t136sm8099875oif.2.2016.11.14.15.20.28 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 Nov 2016 15:20:29 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Tue, 15 Nov 2016 08:20:28 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7071CA02-25D9-4C80-BE08-DC7C22BF8F93@sn3rd.com> References: To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Call for agenda items @ IETF 97 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 23:20:33 -0000 Please note that I=E2=80=99ve been uploading the presentations as I=E2=80=99= ve been getting them; I=E2=80=99m embedding links in the chair slides to = the presenters slides. The chair slides are up to revision 4 (in case = you=E2=80=99ve downloaded them earlier). Still waiting on a couple. Note that Martin will have no slides for the Example Handshake Traces in = TLS 1.3 agenda item. spt > On Oct 24, 2016, at 00:13, Sean Turner wrote: >=20 > The final IETF 97 agenda is out: > https://datatracker.ietf.org/meeting/97/agenda.html >=20 > Please note that there are TWO tls sessions: > 1. Tuesday @ 15:50-18:20 in Park Ballroom 1 > 2. Friday @ 09:30-1130 in Grand Ballroom 2 >=20 > spt >=20 >> On Oct 18, 2016, at 14:07, Sean Turner wrote: >>=20 >> The preliminary IETF 97 agenda is out: = https://datatracker.ietf.org/meeting/97/agenda.html. We=E2=80=99re = currently scheduled for Tuesday @ 15:50-18:20 in Park Ballroom 1. >>=20 >> Please send in agenda requests. But, please note that TLS = 1.3-related issues and WG drafts will be given a priority during the = sessions. We=E2=80=99re also going to give preferential treatment to = drafts that generated discussion on the list. >>=20 >> Cheers, >>=20 >> J&S >=20 From nobody Mon Nov 14 15:21:14 2016 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 F27B4129589 for ; Mon, 14 Nov 2016 15:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 ImrntM5u2qcp for ; Mon, 14 Nov 2016 15:21:11 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 82F1112941C for ; Mon, 14 Nov 2016 15:21:11 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id q124so152757960itd.1 for ; Mon, 14 Nov 2016 15:21:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:date:references:to :message-id:mime-version; bh=jMsB6iWeNZ99f9o4+zdytkPBmmI109XhlHeP1ldYYWs=; b=DvtBoZy0DlcbKgSjAQmnvZs5hkW+PNzsQcbzx0ccV8ko+xqk7Z7l3RCcvdqA/Tyckr Qqli1WD74kgRsQRI/qGV/mtqTAUJM66eRmORF37Qv+uB1zdTFgccUSdJgZgMtNXaQ/67 MO5CMo+Tu2+12US47SSQ9/eZXZe+kRtquP9Jg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject:date :references:to:message-id:mime-version; bh=jMsB6iWeNZ99f9o4+zdytkPBmmI109XhlHeP1ldYYWs=; b=JKBc/88hZlllFZfXDinIPeDLrgN0K/tUVLbZFTwqwpg2AkspftX2zBP1TlDknwHQSY j5NUBwS2yykPbnzstUJ8aOt3XCPsvoWqPHqSU86NhHlD9q0bX2+CJRe9ZqLxcR5Gt6Dj TysXvSW8az1Ludpo5w4yOnUntqxWoZl+tIjk2BGzuDblgkRnEED0u7bmPCTQNXKvoCFY CoOmCGAWRi2kM8nhxc4trKqmWxOSRMKSRteqlCGJqYJdNJvL55PuKI0xJSy4Jolg8otS rIEK1awP4ElqB1JMknh+/+3zqFBBh/fztOMMTfpTxRMZIu8O5K64RvKT3p0tjTSGYyHB BsSg== X-Gm-Message-State: ABUngvcoe6Xvh/EIGF67y+wnQ5yFpl1T+aM9dh4cYEvXd17iljzNHXC79Z5NgaOIjnqxzQ== X-Received: by 10.157.6.227 with SMTP id 90mr7420453otx.73.1479165670771; Mon, 14 Nov 2016 15:21:10 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:cd02:ce70:3008:8583? ([2001:67c:370:144:cd02:ce70:3008:8583]) by smtp.gmail.com with ESMTPSA id t136sm8099875oif.2.2016.11.14.15.21.09 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 14 Nov 2016 15:21:10 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 15 Nov 2016 08:21:09 +0900 References: <147910540903.27914.13476250309001878369.idtracker@ietfa.amsl.com> To: "" Message-Id: <01E37D56-5E8F-417D-B416-1DF35A08C6CE@sn3rd.com> Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 14 Nov 2016 23:21:13 -0000 Please note that this draft is related to the agenda item: - TLS Visibility Inside the Data Center spt > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt > Date: November 14, 2016 at 15:36:49 GMT+9 > To: > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Data Center use of Static Diffie-Hellman in = TLS 1.3 > Author : Matthew Green > Filename : draft-green-tls-static-dh-in-tls13-00.txt > Pages : 4 > Date : 2016-11-13 >=20 > Abstract: > Unlike earlier versions of TLS, current drafts of TLS 1.3 have > instead adopted ephemeral-mode Diffie-Hellman and elliptic-curve > Diffie-Hellman as the primary cryptographic key exchange mechanism > used in TLS. This document describes an optional configuration for > TLS servers that allows for the use of a static Diffie-Hellman = secret > for all TLS connections made to the server. Passive monitoring of = TLS > connections can be enabled by installing a corresponding copy of = this > key in each monitoring device. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Nov 14 16:10:44 2016 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 7E9191294E7 for ; Mon, 14 Nov 2016 16:10:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BO_0W_MY7o4F for ; Mon, 14 Nov 2016 16:10:42 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 73E77126CD8 for ; Mon, 14 Nov 2016 16:10:42 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id q130so116878275qke.1 for ; Mon, 14 Nov 2016 16:10:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=cXWBQFD750C2LT/mXVDR9RDUctVtZjcERjChU5a1ZfA=; b=Uyap0rJXymvcxkuKbUAU8HlyQOTXEFlL5b6ceAcXXquLh3vvjjBW/+w5cLp3Wd6a18 ztFJm/EzeqGalipfV+cT5/8NOuJ88EBzo+MPuhoJqEgcY3PNyAmlIB+vKJ/h0jvrrObX vyVt13WcmWjoW9xBCsAYUMNJ+MR71hpo0Bez3iIhpWPT0k+9iFJvegldmlG7LD1PPhUt YBnK6quQWgWqrodfmpbL63OgEbzj8m+sSKW56thFP1866mrZHVz7y2jtxPddFVZMFC66 s4BXfpwl3TfpOc/04aDFsMAiPKteuX6djoifMEHw+X+RkBW3fFszM8ytjJ4oz1KLK+6z WLOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=cXWBQFD750C2LT/mXVDR9RDUctVtZjcERjChU5a1ZfA=; b=OdUqVErVZ2y4A5rr2wuMcteRNZC8+S+uI11lriuffnVNxAb3vLnqT+f6aRIEQMjQN0 n6wDuiGDbKKkQ2I8W9R8s2cJPZHTERNvF7j4EPh+8MTTotEH9n1/5qEZ64ivphDn0pLN XXV1hOvzQI1Z2iAWc+HyEe8SRDeqIGG6mp/fi6Udib02M1y+jRETN1ujbmddh4zrajgW 1of5RJZ6d7AvrSQTFH96vVYeIb6GOuUbkT0JrJ8tCS5ybYQ90QqMwqsFRbEa1S02yRF+ mcB6v695o4htsm6c3wWihB3JDGIjwh8Xg4bbt62/kM06vQu2jq4+ijOq0LkD0dYG2Gj5 SkQQ== X-Gm-Message-State: ABUngvcEAUZ9tfh3Ym/dEtijykVJNKfm1oXU70CMEgFj1Uep14h0Eattq+rI7yjcL4+3vcTYRmVYoHwjXb5W/w== X-Received: by 10.55.158.199 with SMTP id h190mr21800562qke.202.1479168641595; Mon, 14 Nov 2016 16:10:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 14 Nov 2016 16:10:41 -0800 (PST) In-Reply-To: <1479128315.2624.62.camel@redhat.com> References: <1479128315.2624.62.camel@redhat.com> From: Martin Thomson Date: Tue, 15 Nov 2016 09:10:41 +0900 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 00:10:43 -0000 On 14 November 2016 at 21:58, Nikos Mavrogiannopoulos wro= te: > For draft=E2=80=90mavrogiannopoulos=C2=AD=E2=80=90dtls=C2=AD=E2=80=90cid= =C2=AD=E2=80=9000 and we needed to extend the > DTLS un-authenticated part of the DTLS record header with an additional > field. That works well if this is the only draft ever extending the > DTLS record header. If not, modification order would be undefined. Where is this draft? > Would it make sense to introduce an extension header for DTLS 1.3 in > the lines of the IPv6 extension headers? That would allow TLS extension > negotiation to add more items on the un-authenticated header, and > potentially also remove redundant headers. Without seeing the draft, I can't really say whether this is sensible, but I've been working on trimming the DTLS 1.3 header down to something sane. That might be incompatible with any attempt to add unauthenticated data to the header. From nobody Mon Nov 14 16:28:46 2016 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 AAFE2129552 for ; Mon, 14 Nov 2016 16:28:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 VNUwrEbYrWa6 for ; Mon, 14 Nov 2016 16:28:42 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 C5CBF129538 for ; Mon, 14 Nov 2016 16:28:42 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id a10so82365342ywa.3 for ; Mon, 14 Nov 2016 16:28:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=WNkqxacnDZ/A6i/CVeUda5uA47b1vs2gszp0t9OrAYQ=; b=1APpfuue2dB6MPTES0htQh+hCqUxhYl0qNygABF25+h5EAdiV2joucwTBThfWyIPLm PAFcCf1+m74Kjy8XnIZUUn1sTjsjV01BgffXFIGP/ji8JsiCmFcaj2V3mmcewJ2oPcKn cJrah+gWcXizIGbsOypxQby6vze3LGrkyYNM5AakgiO+MYjzPNHIPh8iXS64ASFkcF0Z DCxpnZ+I+IAzGEmM0PDrZxYCY6wKHEis5FB36YjgInc9B+BWALvb85VFZieijtTFuDHz q+agHZ/1Bwgly9UP1XWnb6hXGssIvGV1X1zUg1w3rbdX1tZraFHz/j7IkVeH6Zaup9yi MRlw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WNkqxacnDZ/A6i/CVeUda5uA47b1vs2gszp0t9OrAYQ=; b=EKalyetMkABqsYuX0p4w1hBNWVkc27qM4WPkYEIsRM6iJMKHs/lt0ijjqxDyBb7Xyn soIr4YPOa/fj3tSJ5kxhtq/gxmdvIdCsZvwOnrv3qTs4HrylULWa15E+9YvRL8xoNjeu Z7MVwlpTrIUFivqkF/dk0wITSjJfZ9IQvsmoV13oeLRj39PGHRjyUnjdubICpBqg+B9y aT7QCzIR/BSqjR9o5U7IAUZvdEp75wW2/3s85xXKpaGt/Bw445COVrB5HngvQW/SSrfh T8KZlgSLJoYCo4kZo80MDe25WcXIhRZKuiBoYNqUmYDdZqw4PMxsjtRTExdk5a/Gsknb i7mw== X-Gm-Message-State: ABUngvde6Z4L32wNbTxPNjHtr+xqqud+2k1GfGoDXAxDBwzFZ9j4/jP3+ElxttFBfAJ3HzqYfKG9WVMYGREzsw== X-Received: by 10.129.81.78 with SMTP id f75mr17413468ywb.149.1479169722105; Mon, 14 Nov 2016 16:28:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 14 Nov 2016 16:28:01 -0800 (PST) In-Reply-To: References: <1479128315.2624.62.camel@redhat.com> From: Eric Rescorla Date: Tue, 15 Nov 2016 09:28:01 +0900 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11456404d9738b05414c0975 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 00:28:45 -0000 --001a11456404d9738b05414c0975 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable One way to split the difference between these two would be to use an extension to negotiate the encrypted record format. -Ekr On Tue, Nov 15, 2016 at 9:10 AM, Martin Thomson wrote: > On 14 November 2016 at 21:58, Nikos Mavrogiannopoulos > wrote: > > For draft=E2=80=90mavrogiannopoulos=C2=AD=E2=80=90dtls=C2=AD=E2=80=90c= id=C2=AD=E2=80=9000 and we needed to extend the > > DTLS un-authenticated part of the DTLS record header with an additional > > field. That works well if this is the only draft ever extending the > > DTLS record header. If not, modification order would be undefined. > > Where is this draft? > > > Would it make sense to introduce an extension header for DTLS 1.3 in > > the lines of the IPv6 extension headers? That would allow TLS extension > > negotiation to add more items on the un-authenticated header, and > > potentially also remove redundant headers. > > Without seeing the draft, I can't really say whether this is sensible, > but I've been working on trimming the DTLS 1.3 header down to > something sane. That might be incompatible with any attempt to add > unauthenticated data to the header. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11456404d9738b05414c0975 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
One way to split the difference between these two would be= to use an extension to negotiate the encrypted record format.

-Ekr

On Tue, Nov 15, 2016 at 9:10 AM, Martin Thomson <= ;martin.thoms= on@gmail.com> wrote:
On 14 November 2016 at 21:58, Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:
>=C2=A0 For draft=E2=80=90mavrogiannopoulos=C2=AD=E2=80=90dtls=C2=AD=E2=80=90cid=C2=AD=E2=80=9000 and we needed to extend the
> DTLS un-authenticated part of the DTLS record header with an additiona= l
> field. That works well if this is the only draft ever extending the > DTLS record header. If not, modification order would be undefined.

Where is this draft?

> Would it make sense to introduce an extension header for DTLS 1.3 in > the lines of the IPv6 extension headers? That would allow TLS extensio= n
> negotiation to add more items on the un-authenticated header, and
> potentially also remove redundant headers.

Without seeing the draft, I can't really say whether this is sen= sible,
but I've been working on trimming the DTLS 1.3 header down to
something sane.=C2=A0 That might be incompatible with any attempt to add unauthenticated data to the header.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a11456404d9738b05414c0975-- From nobody Mon Nov 14 16:35:54 2016 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 8FC94129411 for ; Mon, 14 Nov 2016 16:35:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5zH85jUL19SN for ; Mon, 14 Nov 2016 16:35:52 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 5D3341295A0 for ; Mon, 14 Nov 2016 16:35:51 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id n204so117396129qke.2 for ; Mon, 14 Nov 2016 16:35:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lxgO0ROKcYAR+tf185Z9CNh5wfjxMpwTJUWggUaZXns=; b=gn4nNbgCviiJHC/vzMFG8mXDxQeLLa4CqBT4+uodHAznoUmE6S9+LM3FW04fgS4tgA f3iY7/U+DPgo2tDvYiZiZeEWLWaR5qT6LsO4flqDMngZ5II+U5QalzpP/7FqAsB+fyB3 Qp/RuJabPLAP7pZxV0+hF3H0WWS9+8tZJFuwnoT0HFcSs9Hm0XU3g4IRYxfX+q6zAV17 dbs6BsOWu2id2Q6fZM5ACqOYoXcf6dE92pAaqs4fXeYX47t6YNHkApqLWbhz5jw94qWJ ze9r1aE5WasK2rPPgNbA0KgmFmC3kKCYvagW+09nFzwjVHX/41tzDopUisu7iUgyiX2t /T1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lxgO0ROKcYAR+tf185Z9CNh5wfjxMpwTJUWggUaZXns=; b=lwgmYvK50AItJWntSsS0QCqChxBkTbWDYJKAnb9ktXfc+rkCYheFPgk3ZifeR0ltC4 DIRdp6cXhfYDC1zPTcCGfdskk/YemmQ3dgyWHb/FwZv026h7xba/tagDQHjsFRWqHr4g htZK55SbxGZo8EiiEKO1E++Bnh2l7N+/vl5rUCUgl62Z7CW7pB/ZJyJ12XY/yPEJYE9S cAt991Wuu3sFI5Hh+js7MA9tzS1sc+1fFQPVUn5MomKMI5axpqdJvkv+Dfm6iW2n7HL5 5/JI1eagjY0JKO67niCYkBkHQT+p1lW7RSr73txv8rhMMMttGMt8SOqkv7xnYOK4r4rN 196A== X-Gm-Message-State: ABUngvc50apSr7+Y17IA7ZSuVDe3p/eKhxlI+jj8GSWjgz5Cm/BWnz86bf7RS+LFdVR6dkxHbYNIw4EPa8JRPA== X-Received: by 10.55.12.2 with SMTP id 2mr19606636qkm.68.1479170150582; Mon, 14 Nov 2016 16:35:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 14 Nov 2016 16:35:50 -0800 (PST) In-Reply-To: References: <1479128315.2624.62.camel@redhat.com> From: Martin Thomson Date: Tue, 15 Nov 2016 09:35:50 +0900 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 00:35:53 -0000 On 15 November 2016 at 09:28, Eric Rescorla wrote: > One way to split the difference between these two would be to use an > extension to negotiate the encrypted record format. Yes, that could work. It would need special rules for 0-RTT, but in theory a negotiated extension could do anything to the protocol. From nobody Mon Nov 14 16:39:43 2016 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 6721412957F for ; Mon, 14 Nov 2016 16:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 2t_w3X_sEsNq for ; Mon, 14 Nov 2016 16:39:40 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 2D125129411 for ; Mon, 14 Nov 2016 16:39:40 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id r204so82487730ywb.0 for ; Mon, 14 Nov 2016 16:39:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OP8BL+eCCWgsNBINknPYRGVm1gmr65frpGMN6DMFcJA=; b=lyTmBX20HVxy6y1p/ULmzYALWdYAYwi8P8Lr1rbgVfXu9HdwmQDP+pO74Wblh3hDyZ U5kgq3d8iBtGJvDthzoDlMzUZp+Wrfxn7CBQ8F+Np0TKQSiiyBe20pNy/4y17+JddfBZ uDV1xnn2482pEtk4fdeYR++PdEavOUUscUiDrEUAK9XJ83jqvUvGMbMLOin6L3KM/+Os +Xi+XEW5JhZlf0M8hBcNjTp+iTzSbXFBLagouD0KkHl3TkcMOR1QfwEaJMiGToqim2f6 TKdk5SSzdIIL6t/9A+XV3PW45ELdfKnbqA7gEnhf06tvpMjgjYOyAiGJ7ovQSX6Tqibn biXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OP8BL+eCCWgsNBINknPYRGVm1gmr65frpGMN6DMFcJA=; b=JMyiYPUJ3Fz/i6AbePE/VjRQ09iR835wyh6CjaQf/YEjYIVLus28gnZHF9GoyunA/C YUvWHQFoqKE9rmJrBRA3WKFEvTUEgP7+rPtgKWpvtk8fpRmuE481wR0pUpOa/AKgaMbA Y7h7Cya3yl3AWZB8hZalMh8Zj0D7kRpDjqncHJ1OH26lweRmUJxhBwID8rn/wITBB1pR yVeSurpxan1keRQ7EWDTi9Blaz82VMnyaRxMRb+VUk7IGUFt4sjvl0aWrzbeDRXy0hUW eGcgM6GDxIwu+C0OtKnlnONVIz8zpc2l/Lg5qGstgONVyTpYoeKfjHMmfncCGON3oYLw VqoQ== X-Gm-Message-State: ABUngve8wFQYLS49NTxU/z7UK/uPZlrePXNhL8wdqGr9f+CXQb9ejmB1bO2Z+u/ROiwq1zLPCJUnbwslasRoIA== X-Received: by 10.129.53.194 with SMTP id c185mr17160657ywa.205.1479170379530; Mon, 14 Nov 2016 16:39:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 14 Nov 2016 16:38:59 -0800 (PST) In-Reply-To: References: <1479128315.2624.62.camel@redhat.com> From: Eric Rescorla Date: Tue, 15 Nov 2016 09:38:59 +0900 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1142147809007205414c316c Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 00:39:41 -0000 --001a1142147809007205414c316c Content-Type: text/plain; charset=UTF-8 See also PR#762 -Ekr On Tue, Nov 15, 2016 at 9:35 AM, Martin Thomson wrote: > On 15 November 2016 at 09:28, Eric Rescorla wrote: > > One way to split the difference between these two would be to use an > > extension to negotiate the encrypted record format. > > > Yes, that could work. It would need special rules for 0-RTT, but in > theory a negotiated extension could do anything to the protocol. > --001a1142147809007205414c316c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
See also PR#762

-Ekr


On Tue, N= ov 15, 2016 at 9:35 AM, Martin Thomson <martin.thomson@gmail.com> wrote:
On 1= 5 November 2016 at 09:28, Eric Rescorla <ekr@rtfm.com> wrote:
> One way to split the difference between these two would be to use an > extension to negotiate the encrypted record format.


Yes, that could work.=C2=A0 It would need special rules for 0-RTT, b= ut in
theory a negotiated extension could do anything to the protocol.

--001a1142147809007205414c316c-- From nobody Mon Nov 14 17:00:00 2016 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 56959129593 for ; Mon, 14 Nov 2016 16:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=iij.ad.jp 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 w-gn-MxqJ7bh for ; Mon, 14 Nov 2016 16:59:57 -0800 (PST) Received: from omgo.iij.ad.jp (mo901.iij.ad.jp [202.232.31.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255311293FC for ; Mon, 14 Nov 2016 16:59:57 -0800 (PST) DKIM-Signature: v=1;a=rsa-sha256;c=relaxed/simple;d=iij.ad.jp;h=Date: Message-Id:To:Cc:Subject:From:In-Reply-To:References:Mime-Version: Content-Type:Content-Transfer-Encoding; i=kazu@iij.ad.jp; s=omgo2; t=1479171594; x=1480381194; bh=WeCYzLkCsyxP7cHehjoi8+EuFni1FhgQjEZt5bJk4/8=; b=CTX7Zi1ZSZ9Luv fs9XlDbhI+hm6BjoKlmwjMAj1e7ICKo2O4sPgac+Q3A5Oc9YewNPXAX6vftlAoS9rwP+2y5X/+Xwt EjzvN1rs0BAyESkpkMkICHiQKe1cqu122dHOhfOWWfqWM7CWWcmiuRSkHpdaVKJdp7snuBMZgrWST ClUqN1euEy+Hrdhb1HqpVBDv/4NO6kUVwEzgVjWIAkea7BNyNjM8YaP1aWeF6UW+8Y8jNQxXsUPid L8faeDNJzoBSd+4QkElQJ/nDK8vS83ZJrpgINhO3/TxoAz+SkFhYhEcrW1fuKD7mWic1tOeCt8wPk VZCAUL/Br2AD7tHMBEbQ==; Received: by omgo.iij.ad.jp (mo901) id uAF0xrrV016270; Tue, 15 Nov 2016 09:59:54 +0900 X-MXL-Hash: 582a5e0971480043-c6477473d636dad879c9cb956ce1564de4019e95 Date: Tue, 15 Nov 2016 09:59:54 +0900 (JST) Message-Id: <20161115.095954.324898166298702034.kazu@iij.ad.jp> To: martin.thomson@gmail.com From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) In-Reply-To: References: <147908236337.5607.3896025791064163090.idtracker@ietfa.amsl.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Fwd: New Version Notification for draft-thomson-tls-tls13-vectors-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 00:59:58 -0000 Hello Martin, > I've updated the test vectors draft. > > The vectors should now be correct with respect to draft-18. I > implemented exporters as well, so calculations for those are now > shown. Thank you for very useful document. I would be nice if this example includes secp256r1 instead of (or in addition to) x25519 as I guess that many TLS 1.3 implementations implement secp256r1 first. --Kazu From nobody Mon Nov 14 17:10:22 2016 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 3ABA2129605 for ; Mon, 14 Nov 2016 17:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 TnYpSE2r9J9s for ; Mon, 14 Nov 2016 17:10:18 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA6A1293FC for ; Mon, 14 Nov 2016 17:10:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 77C15BE64; Tue, 15 Nov 2016 01:10:15 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEVVMEUJBj9W; Tue, 15 Nov 2016 01:10:14 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id B4E62BE5F; Tue, 15 Nov 2016 01:10:13 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1479172214; bh=JcV3NbutOuI4lIhcWeTcJBbliquze3bBdAjxhmUgs2E=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=YdwHEL+atzal8raaIWVE1FMjf8ikh5B9sFPHXShe7pB5nVFMrR0yYL/Z5vywQ085L 69sPbQxzlkc5NgqJsbtdgvJCplxsT89d4wZRVSdV+deDdo7HgTttrZHfVl38jL3aje yyVTsUP5o2agjr/IOntDrT1D6adtrYoXIky1CiXE= To: Nikos Mavrogiannopoulos , "tls@ietf.org" References: <1479128315.2624.62.camel@redhat.com> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> Date: Tue, 15 Nov 2016 01:10:13 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1479128315.2624.62.camel@redhat.com> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms070704000200020800010107" Archived-At: Cc: Hannes Tschofenig Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 01:10:20 -0000 This is a cryptographically signed message in MIME format. --------------ms070704000200020800010107 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 14/11/16 12:58, Nikos Mavrogiannopoulos wrote: > Hi, > For draft=E2=80=90mavrogiannopoulos=C2=AD=E2=80=90dtls=C2=AD=E2=80=90c= id=C2=AD=E2=80=9000 and we needed to extend the > DTLS un-authenticated part of the DTLS record header with an additional= > field. That works well if this is the only draft ever extending the > DTLS record header. If not, modification order would be undefined. >=20 > Would it make sense to introduce an extension header for DTLS 1.3 in > the lines of the IPv6 extension headers? That would allow TLS extension= > negotiation to add more items on the un-authenticated header, and > potentially also remove redundant headers.=20 I'd be interested in an analysis of the potential privacy impacts of this. Isn't this more or less the same as doing SPUD-for-DTLS? (If not, sorry for dragging in controversy:-) S. >=20 > What do you think? >=20 > regards, > Nikos >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --------------ms070704000200020800010107 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMTUw MTEwMTNaMC8GCSqGSIb3DQEJBDEiBCB2O9rB694zHD6Ef/Gqi/3skHjNZqV/VrYCJif5LNno mjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQCJ4l3zmBR0/jMwKtexJn+QnMmaP+qVrwtIq6hBbPMFESOzZGBZ7Mr6 Ge4/+CMO8NGBdTEisrLOm9yparyBmgmlwZlyXgYBX0wlqJj9+U+NKV/M/s6J80j3oo3a0SYH tQ50eeUnIPIOZJlLdhIwS6/hTAQX0KVmJ9oTuWLwrR+puKKucZ2EyFWOhWuNfrjQAPJJRgOL 0i6MsW4i97Q77/0ebNlXMeph+KM8a0VoPprLlqBlifsuJuch1AHfYKioJvhFH0j+6mx6SiCI cX8QX+60gbTy2EtGXjFJRqCoj4rdBvSl4IFFxPDtwWJjAPkerTG3jhUXNNfvL3uQsUeboCa8 AAAAAAAA --------------ms070704000200020800010107-- From nobody Mon Nov 14 17:17:10 2016 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 33CA512960A for ; Mon, 14 Nov 2016 17:17:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 2wYTRlf41b3m for ; Mon, 14 Nov 2016 17:17:07 -0800 (PST) Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 E13D61293FC for ; Mon, 14 Nov 2016 17:17:06 -0800 (PST) Received: by mail-yb0-x22b.google.com with SMTP id d128so30497605ybh.2 for ; Mon, 14 Nov 2016 17:17:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GqG7ASWScU1GrDIQ7dQ24dj7XtWnB67m7MmBAf2fjaY=; b=GkmNk9QP3cEVtv37ovCK3PYctxx+ZgP/j/DBgGxKG/Qj6uMjmb92ur47eIkhAby3Al jjSZxenn3LV7ktBxPJE+sphIUj2EVBNkqe6eI8Y+SFgijfGzoxCHFH1tIxrw6G2CERJQ CKTxvhrldGyhSOT5UUaulnxsHv/2OsduXrTbEqXt9ZQT/jOIxqxTvaeMrFp2rei5Dd/H /w9IuPcmGoQmRKQaJtZjBd1eXK65X+Ab2MFjEabyXOYEhXB7RokNvWJUm3qbIRfIrTBl Eas3otszwHO64uLuCwWlsBHAmQcFgkx4/WIdScD4DZ6WU1x5+A0g7fHfY2I+nvFGx9bw rNAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GqG7ASWScU1GrDIQ7dQ24dj7XtWnB67m7MmBAf2fjaY=; b=EdZkBYSVIVpK35QD4dPRx+pzGpUblLcWy5hYnfif2Sentfe+ilvQ8vjCzR071X6HCL FpJMa8jKZR9E5gFc09eqvR+uBZ03A/kR7lQXAyJooyY0rfcQXpxkHm/zR/q54jdLryBS aNJagqsHnUYPxVwt6lnhef3VzmRC1iID9rAmsy0MDgNxpx4BYDy1RAlpirF7vDDjesF7 ei3PZb5kzfYyw/izuY50kDlA/Dr+CtqC85PEWyyQFGmaxm3+ke2qVIj6yqiVuZbBCkQf 7KPyosluOeBABvoXkO9N+D0MKHDmFiodW0XsbtbKI5XhvXEzPjb4UOD0r103Y6DnnGu7 l19w== X-Gm-Message-State: ABUngveFPOtaNlY8OMaNdgLOy2mO9u1+mtHr+ecq6qhGShex9wpq1VXqVLikXet4OCZhNLmPSLOFZfioYIPvFA== X-Received: by 10.37.160.41 with SMTP id x38mr18283864ybh.64.1479172626190; Mon, 14 Nov 2016 17:17:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 14 Nov 2016 17:16:25 -0800 (PST) In-Reply-To: <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> From: Eric Rescorla Date: Tue, 15 Nov 2016 10:16:25 +0900 Message-ID: To: Stephen Farrell Content-Type: multipart/alternative; boundary=94eb2c1a0650f242bb05414cb65b Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 01:17:08 -0000 --94eb2c1a0650f242bb05414cb65b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Nov 15, 2016 at 10:10 AM, Stephen Farrell wrote: > > > On 14/11/16 12:58, Nikos Mavrogiannopoulos wrote: > > Hi, > > For draft=E2=80=90mavrogiannopoulos=C2=AD=E2=80=90dtls=C2=AD=E2=80=90c= id=C2=AD=E2=80=9000 and we needed to extend the > > DTLS un-authenticated part of the DTLS record header with an additional > > field. That works well if this is the only draft ever extending the > > DTLS record header. If not, modification order would be undefined. > > > > Would it make sense to introduce an extension header for DTLS 1.3 in > > the lines of the IPv6 extension headers? That would allow TLS extension > > negotiation to add more items on the un-authenticated header, and > > potentially also remove redundant headers. > > I'd be interested in an analysis of the potential privacy > impacts of this. Isn't this more or less the same as doing > SPUD-for-DTLS? (If not, sorry for dragging in controversy:-) > It would no doubt depend what you put there. -Ekr > > S. > > > > > What do you think? > > > > regards, > > Nikos > > > > _______________________________________________ > > 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 > > --94eb2c1a0650f242bb05414cb65b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 15, 2016 at 10:10 AM, Stephen Farrell <= ;stephen.far= rell@cs.tcd.ie> wrote:


On 14/11/16 12:58, Nikos Mavrogiannopoulos wrote:
> Hi,
>=C2=A0 For draft=E2=80=90mavrogiannopoulos=C2=AD=E2=80=90dtls=C2=AD=E2=80=90cid=C2=AD=E2=80=9000 and we needed to extend the
> DTLS un-authenticated part of the DTLS record header with an additiona= l
> field. That works well if this is the only draft ever extending the > DTLS record header. If not, modification order would be undefined.
>
> Would it make sense to introduce an extension header for DTLS 1.3 in > the lines of the IPv6 extension headers? That would allow TLS extensio= n
> negotiation to add more items on the un-authenticated header, and
> potentially also remove redundant headers.

I'd be interested in an analysis of the potential privacy
impacts of this. Isn't this more or less the same as doing
SPUD-for-DTLS? (If not, sorry for dragging in controversy:-)

It would no doubt depend what you put there.

-Ekr
=C2=A0

S.

>
> What do you think?
>
> regards,
> Nikos
>
> _______________________________________________
> 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


--94eb2c1a0650f242bb05414cb65b-- From nobody Mon Nov 14 17:28:15 2016 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 548D3129630 for ; Mon, 14 Nov 2016 17:28:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBCCHzUjUJrO for ; Mon, 14 Nov 2016 17:28:11 -0800 (PST) Received: from mail-pf0-x229.google.com (mail-pf0-x229.google.com [IPv6:2607:f8b0:400e:c00::229]) (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 8D2A21295D0 for ; Mon, 14 Nov 2016 17:28:11 -0800 (PST) Received: by mail-pf0-x229.google.com with SMTP id i88so32437079pfk.2 for ; Mon, 14 Nov 2016 17:28:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5QiRuYJlLWB47W8nhs1I63hjGLHYeI6BFxYMhCFM4SE=; b=RIriyu9CAYI015aHjeE9RLZ1QzzZx5Ojhp0ud5VVA1HiFdg1ekRVGu5i2QTm4akrxq 2+Ohw60dkaU4JdYFg/+AA/VyVnxbc+PRH9W4lttZqQhv1vO+k3A9QyfJGVNDBuPYlSY3 bql3FUrEKQHmTdQIAzyZUjc7PXxj0zfHBzeqO1bO5ZuWH4nKOGSOsqtO6TGkBSN5pfr1 s2AnZajBmkeR+ab/rZqRPRK9cICV1n8TmqS5EX2ljGK4XV+0tPRz6ZtscuwN2+x8K9mo 7o/kcAY80hibMduTSEdKoj7xHyOfOmQvkcSYHwNLzJq1BHVyAm8djOp1+p12iL3VrVMr 2jQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=5QiRuYJlLWB47W8nhs1I63hjGLHYeI6BFxYMhCFM4SE=; b=XuigPc889UxKIcfU36S0aptH5LSQ25DEfHFX1vREwiruv3KgK2t+4n4diQowwA0LTp av0W0KwRPD0kVjXwGOQuLI9folssY+3t4beZdMLJ5JHibWWklFYXeBGmRbg5ZhSm/NFA NgSXzH0u+IcjCYgKYvLPiA/TRRd4OWiytt95nNkGQrcX6hMr5EdvVgnS0mnx6CIBKMeg NuwogFKxb8tu1QJjEsRZSho1Pqh7FV/oX2CGGPcB8+4IOTAdg0tXaTM+FT6vi89fxBKH 3NGP5TEUgBqrQAkNJdjygbnAMBiF49Mx2Rlhi/d+5b1i4xs2n/toT8La6BpZL2hrAVXj fO0Q== X-Gm-Message-State: ABUngvcIEWHYRPbMQsOyMhc0lzg3St9jwHLR5ztjbanmh9lTOcVDtINgVBny0AxF8LMwYw== X-Received: by 10.98.80.140 with SMTP id g12mr41646996pfj.54.1479173291180; Mon, 14 Nov 2016 17:28:11 -0800 (PST) Received: from t2001067c03700128a089594b13383426.v6.meeting.ietf.org ([2001:67c:370:128:a089:594b:1338:3426]) by smtp.gmail.com with ESMTPSA id p79sm2599842pfj.51.2016.11.14.17.28.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 14 Nov 2016 17:28:10 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: <01E37D56-5E8F-417D-B416-1DF35A08C6CE@sn3rd.com> Date: Tue, 15 Nov 2016 10:28:05 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2F41D793-19E2-4C04-A914-E2F2581F844E@gmail.com> References: <147910540903.27914.13476250309001878369.idtracker@ietfa.amsl.com> <01E37D56-5E8F-417D-B416-1DF35A08C6CE@sn3rd.com> To: Sean Turner X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "" Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 01:28:13 -0000 If I understand this draft correctly, this draft describes server = behavior. It does not change anything within the TLS 1.3 protocol. IOW a = server doing this will interoperate with any client. I searched the tls13 draft to see if it has anything to say about this, = and the only thing I found was this line in appendix D.1: If fresh (EC)DHE keys are used for each connection, then the output = keys are forward secret. So a server is not required to generate fresh (EC)DHE keys for each = connection. In fact, generating fresh keys periodically and discarding = the old ones are a legitimate way to achieve forward secrecy. What this = draft does differently is to save the old (EC)DHE private keys, which = loses the forward secrecy.=20 So given that what the draft proposes is possible with the current TLS = 1.3, what do the proponents want? Is it just to have a document that = describes this server behavior? Yoav On 15 Nov 2016, at 8:21, Sean Turner wrote: > Please note that this draft is related to the agenda item: >=20 > - TLS Visibility Inside the Data Center >=20 > spt >=20 >> Begin forwarded message: >>=20 >> From: internet-drafts@ietf.org >> Subject: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt >> Date: November 14, 2016 at 15:36:49 GMT+9 >> To: >> Reply-To: internet-drafts@ietf.org >>=20 >>=20 >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>=20 >>=20 >> Title : Data Center use of Static Diffie-Hellman in = TLS 1.3 >> Author : Matthew Green >> Filename : draft-green-tls-static-dh-in-tls13-00.txt >> Pages : 4 >> Date : 2016-11-13 >>=20 >> Abstract: >> Unlike earlier versions of TLS, current drafts of TLS 1.3 have >> instead adopted ephemeral-mode Diffie-Hellman and elliptic-curve >> Diffie-Hellman as the primary cryptographic key exchange mechanism >> used in TLS. This document describes an optional configuration for >> TLS servers that allows for the use of a static Diffie-Hellman = secret >> for all TLS connections made to the server. Passive monitoring of = TLS >> connections can be enabled by installing a corresponding copy of = this >> key in each monitoring device. >>=20 >>=20 >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-green-tls-static-dh-in-tls13/ >>=20 >> There's also a htmlized version available at: >> https://tools.ietf.org/html/draft-green-tls-static-dh-in-tls13-00 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories: http://www.ietf.org/shadow.html >> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Nov 14 19:51:01 2016 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 12DF1129473 for ; Mon, 14 Nov 2016 19:50:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiCFC-ZNkD2k for ; Mon, 14 Nov 2016 19:50:47 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (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 E37271294AE for ; Mon, 14 Nov 2016 19:50:46 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id w33so60501292qtc.3 for ; Mon, 14 Nov 2016 19:50:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=eAhvCGx1n0+ep45kRdJSqrKRzbOgcrUEm6UqGvla5wQ=; b=mPfOZ9gr8byGiXOF/GvQixsW8+iZdTDUAyQdDXw67GKQZOuAmpOlphOlmTr+glvy0G etQxwMjUWzzGwDnLdoaKwKundBKQOA2W0o1oswWeNwZZCn3yS+54P/YJoLgHidtk58eb AnXIus0V1S8jOn2zY3UovkH8ooFVCVW1DUgXoYOa3HiFSjnH8fm//Nmz94IEK9reuUTW ohohaRVnnPuEgk31FJKz4OF7JDpuRfjmXYkYy/fchWMjIvi16mYfj3nACyPIUC6/kgXF LMfcuU/8GQ8ufbsccZujUZDVghF3k/EAGbyi+/E13iAheXkJ+hIP08xXM0HyhcByAVdt 51dQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=eAhvCGx1n0+ep45kRdJSqrKRzbOgcrUEm6UqGvla5wQ=; b=Z9XHoK+Ue26PxMrTL9QlLJNM9l2TjZ4P30WDctQyJ8oDGRx0Kx+jyMsu6MVebGLzJj QNiY7VZ4RlnFDKpf13SDiRu9VmeZO1RGuwMw9S/TS7qXSvGLqQuwEi8JSLd4UztpfdXb EH65a29WyiNlNbkBPz6ChTzphdAwc69OTL3qdN04AeOoG4RZDRcAyAVAo4ME2oDGiWSz F8HIn/8ZEKIploMSByTXuHbVBErxcbS8BYUKg7ib5ggcaEeqBFeXvIrHLIRsClL5BESF Rmz8wLcnQoj1kQ3mR9mq1oqrNwNxY1sqZEtYOTEeTlYOG/AQ76t81ZP8IM1un8wfsrL7 tkDg== X-Gm-Message-State: ABUngvffRqC8KR5Osh5xXExXraXL7ao5kop+PZul3TQlTchgmLs0FIF/4UQZ6OuI2Aa/1KnvGTlyuora+bluPA== X-Received: by 10.200.44.27 with SMTP id d27mr9972851qta.278.1479181846083; Mon, 14 Nov 2016 19:50:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 14 Nov 2016 19:50:45 -0800 (PST) In-Reply-To: <20161115.095954.324898166298702034.kazu@iij.ad.jp> References: <147908236337.5607.3896025791064163090.idtracker@ietfa.amsl.com> <20161115.095954.324898166298702034.kazu@iij.ad.jp> From: Martin Thomson Date: Tue, 15 Nov 2016 12:50:45 +0900 Message-ID: To: Kazu Yamamoto Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Fwd: New Version Notification for draft-thomson-tls-tls13-vectors-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 03:50:59 -0000 On 15 November 2016 at 09:59, Kazu Yamamoto wrote: > I would be nice if this example includes secp256r1 instead of (or in > addition to) x25519 as I guess that many TLS 1.3 implementations > implement secp256r1 first. That should be easy to add. I can add a 1-RTT handshake with P-256. In the interest of brevity, I might also combine that with other requests for variations. Opened https://github.com/martinthomson/tls13-vectors/issues/1 From nobody Mon Nov 14 19:51:57 2016 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 C68741294AE for ; Mon, 14 Nov 2016 19:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bFUQtswQn2bF for ; Mon, 14 Nov 2016 19:51:54 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (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 6837F1293F3 for ; Mon, 14 Nov 2016 19:51:54 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id q130so121528726qke.1 for ; Mon, 14 Nov 2016 19:51:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0R+OU92U3Jr3mal0sCUstKeSHHW0RIR+8IsQrAlY4mo=; b=V1Ez5q+pogS3iKxzgSxl1MpRaH9bmYkgmjzJP7vIgHoHThq08lbbyj9dztP12Ph+k2 MgomGBn/wSmZBgjIttiSbo447prnTxP/Wf0Ukge5BjSZUsSRorsCtv95IDz92tEejG4G l4QGjzqGApLTyMnuAY5+zPG3tV6X7fxVaO+wru2XpvkI7VW8XvNAmiIf65zVyle8O3dx nCsGguj08I20PAY9IRBTL1i73uD8WgsuYIDUmkvfR2UDZUyigxa5YQoTl1Kt98cGNCij e8LeUaXz5CagMsgWbI9KruObhkGYGpDLzfox9RHbzXtHgpOBW0pM9jvHrrmE57TWtpne Bpxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0R+OU92U3Jr3mal0sCUstKeSHHW0RIR+8IsQrAlY4mo=; b=W2DcuMC2bOHk95A775mZ5OQQ3mJ0676cgS0SRkpQ0uKj40aWzG6e/2IkL2t7jOMkss GYQYLHvGWVGLXqQnd4g4YEKx1tgUd3KanRpD5AgvJwjtYYqLKIZXZDspfmZH73/wAm/Y vm5+//e0z14MOfQQPfRiFTtBF0fver2eFNG7DvXMTX90M2BnFJvf7R28kZI/g0DMAU/r OoLJk+nfKjyYp4P/ey0BIO1gl9V5pnFmnklr7xqnulcaDTm8uYd7B6ufMrvOMpFcIqPM PKi+IWphfoHMMlHSJ8OVKotCuv+3MGwEFyUf+ejG7I0L9UzA7sLwpcSItWNZT0c6m56i YPjA== X-Gm-Message-State: ABUngvdIkC5ZsX2a2v62PrQBhK4DoaQoAc+u1TRPgqJmkJzVqjIZVAegPkE14XVAi63rIyUXfiyT2JP53ggVAw== X-Received: by 10.55.74.1 with SMTP id x1mr21859555qka.316.1479181913603; Mon, 14 Nov 2016 19:51:53 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 14 Nov 2016 19:51:52 -0800 (PST) In-Reply-To: References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> From: Martin Thomson Date: Tue, 15 Nov 2016 12:51:52 +0900 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 03:51:56 -0000 On 15 November 2016 at 10:16, Eric Rescorla wrote: >> I'd be interested in an analysis of the potential privacy >> impacts of this. Isn't this more or less the same as doing >> SPUD-for-DTLS? (If not, sorry for dragging in controversy:-) > > > It would no doubt depend what you put there. Which is why I'm interested in seeing Nikos' (unpublished?) draft. From nobody Mon Nov 14 23:08:19 2016 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 C513112950D for ; Mon, 14 Nov 2016 23:08:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ikdVT1EKVn98 for ; Mon, 14 Nov 2016 23:08:14 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 505BE12944D for ; Mon, 14 Nov 2016 23:08:13 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id C85788F2DB32B; Tue, 15 Nov 2016 07:08:09 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAF78ARn007719 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2016 07:08:10 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uAF789wB010929 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2016 08:08:09 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.241]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Tue, 15 Nov 2016 08:08:09 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Martin Thomson , Eric Rescorla Thread-Topic: [ALU] Re: [TLS] extending the un-authenticated DTLS header Thread-Index: AQHSPt0O+AfDv6+oO0izjrGJ+j67XaDZLUaAgAArbwCAADbSgA== Date: Tue, 15 Nov 2016 07:08:08 +0000 Message-ID: References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <9501F3DB70C3784F9ED2B6E1A65E8EC9@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 07:08:16 -0000 On 15/11/2016 03:51, "TLS on behalf of Martin Thomson" wrote: >On 15 November 2016 at 10:16, Eric Rescorla wrote: >>> I'd be interested in an analysis of the potential privacy >>> impacts of this. Isn't this more or less the same as doing >>> SPUD-for-DTLS? (If not, sorry for dragging in controversy:-) >> >> >> It would no doubt depend what you put there. > >Which is why I'm interested in seeing Nikos' (unpublished?) draft. Published: https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-cid-00 Working copy: https://thomas-fossati.github.io/draft-tls-cid/ Slides for today, "DTLS Optimizations for IoT Deployments": https://www.ietf.org/proceedings/97/slides/slides-97-tls-dtls-optimizations -for-iot-deployments-00.pptx From nobody Mon Nov 14 23:13:03 2016 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 A35CA1295EF for ; Mon, 14 Nov 2016 23:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.419 X-Spam-Level: X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 jMu153ZRXGrr for ; Mon, 14 Nov 2016 23:13:01 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1D27512956B for ; Mon, 14 Nov 2016 23:13:01 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A58168F22B; Tue, 15 Nov 2016 07:13:00 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.106]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAF7Cwj8021726 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Nov 2016 02:12:59 -0500 Message-ID: <1479193977.12027.7.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Stephen Farrell , "tls@ietf.org" Date: Tue, 15 Nov 2016 08:12:57 +0100 In-Reply-To: <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Tue, 15 Nov 2016 07:13:00 +0000 (UTC) Archived-At: Cc: Hannes Tschofenig Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 07:13:02 -0000 On Tue, 2016-11-15 at 01:10 +0000, Stephen Farrell wrote: > > Would it make sense to introduce an extension header for DTLS 1.3 > > in > > the lines of the IPv6 extension headers? That would allow TLS > > extension > > negotiation to add more items on the un-authenticated header, and > > potentially also remove redundant headers.  > > I'd be interested in an analysis of the potential privacy > impacts of this. Isn't this more or less the same as doing > SPUD-for-DTLS? (If not, sorry for dragging in controversy:-) You can check the security considerations section of the latest draft: https://github.com/thomas-fossati/draft-tls-cid/blob/master/draft-mavrogiannopoulos-tls-cid.md TLDR; the privacy offered by this extension is the same as the privacy of DTLS over UDP. regards, Nikos From nobody Mon Nov 14 23:16:50 2016 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 5CD821295EF for ; Mon, 14 Nov 2016 23:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6nvkMv8lDz0d for ; Mon, 14 Nov 2016 23:16:47 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (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 5ACEF12944D for ; Mon, 14 Nov 2016 23:16:47 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id x186so82429264vkd.1 for ; Mon, 14 Nov 2016 23:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=+bt94Q0J1mKTKsm/a8vcLXirhQvVpqI6TMPGBCu8AIg=; b=YV7GbL52wAv4qObkUTk8/QviffdDTzC7BWl6Oxfbj7gOIboPHuKZaMHTzPIcVgW5T6 AEfweP9eDh3xCC+ZS852J4YVTuOQV5RBbSa8XkUMJOzQjaTRmWPhMUitmZgsUoBo3H5v WV2YPEJAmqNWWw/qbwpxKgp60dEf9B9N+rIZqNXArQJs74ORHssvRiRcFwYoJQ3omNWE P68yCP0upbKekagmT9Jm2WIyC5pn44sD2lTYFo2tNir5ow3SDBm5ClAT2ygjd47s+QcG dmfSMyrx+jQfUgixDp/AjbAIzvqHaB4Wxk8uEFaM0zdK3fL13Wk5AmxWkK9bk/EyR7Dh Tnng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+bt94Q0J1mKTKsm/a8vcLXirhQvVpqI6TMPGBCu8AIg=; b=ZlqwfoJof8FG/Q+x2rnBtFDHVUw8jZKh/I1GDYKo/AtAyOHeUZTwiQMkwQi5g4hNEc ZlsWEMWM/AqWDbxswvXGlcmwu47AEV7UMJ/hjbKuYJgtNtVQj/g9N+0f2MvdsfYVG3Zx LxmZh0wmCWXc8XO/FwKQuyQJLP+5YGdNS8ocXfH5yuBWVZZl78FveS6dnOu4ffdXMm28 iDytp7fiPMbPGvBwulW8QlmeWKPszn42KH6VgyFd0tNQ+TUYj6tLbBaCNybxLAenQ5Fg L4GKvebY1YpAf59k0DI8QAKMQOKA6sdJeEk1wqRxxr5/euWksIbKEBEJ9E+uxivRdGfG xQaA== X-Gm-Message-State: ABUngvc3SpUBIFoPRrjDJmNNo8tiQzHUgwgAmuF1ehAA8vUMHQM0Fr7iOZiF+rI5tqIje704zz87K8cgovoY4w== X-Received: by 10.31.162.72 with SMTP id l69mr12680584vke.123.1479194206099; Mon, 14 Nov 2016 23:16:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Mon, 14 Nov 2016 23:16:45 -0800 (PST) From: Watson Ladd Date: Mon, 14 Nov 2016 23:16:45 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114368da356c57054151bda1 Archived-At: Subject: [TLS] Point validation in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 07:16:48 -0000 --001a114368da356c57054151bda1 Content-Type: text/plain; charset=UTF-8 Hello, There has been a lot of chatter on Gitub about point validation. I think it's important to note that in TLS 1.3 the Triple Handshake variants enabled by small subgroup attacks are no longer a threat: the issue is reuse of ephemeral Diffie-Hellman exponents, resulting in compromise of what is effectively a long-term key. I would want a belt and suspenders approach: no use of ephemeral exponents, and validation that points are on the curve. Order validation is unnecessary as the cofactor is small: in cases where it is not the curve probably shouldn't be used without a good reason, and I can't think of any. I know one implementation does keep ephemeral exponents indefinitely. This implementation also validates orders, which equals the expense of not regenerating ephemeral exponents. Sincerely, Watson --001a114368da356c57054151bda1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

There has been a lot of chatter = on Gitub about point validation. I think it's important to note that in= TLS 1.3 the Triple Handshake variants enabled by small subgroup attacks ar= e no longer a threat: the issue is reuse of ephemeral Diffie-Hellman expone= nts, resulting in compromise of what is effectively a long-term key.
<= div>
I would want a belt and suspenders approach: no use of e= phemeral exponents, and validation that points are on the curve. Order vali= dation is unnecessary as the cofactor is small: in cases where it is not th= e curve probably shouldn't be used without a good reason, and I can'= ;t think of any.

I know one implementation does ke= ep ephemeral exponents indefinitely. This implementation also validates ord= ers, which equals the expense of not regenerating ephemeral exponents.=C2= =A0

Sincerely,
Watson
--001a114368da356c57054151bda1-- From nobody Mon Nov 14 23:27:07 2016 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 90DA4129A26 for ; Mon, 14 Nov 2016 23:27:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.419 X-Spam-Level: X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 OJILroQ_rsC9 for ; Mon, 14 Nov 2016 23:27:05 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4530B12956B for ; Mon, 14 Nov 2016 23:27:05 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 65BB73D94E; Tue, 15 Nov 2016 07:09:19 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.106]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAF79Hti029226 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Nov 2016 02:09:18 -0500 Message-ID: <1479193757.12027.4.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Martin Thomson Date: Tue, 15 Nov 2016 08:09:17 +0100 In-Reply-To: References: <1479128315.2624.62.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 15 Nov 2016 07:09:19 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 07:27:06 -0000 On Tue, 2016-11-15 at 09:10 +0900, Martin Thomson wrote: > On 14 November 2016 at 21:58, Nikos Mavrogiannopoulos m> wrote: > > > >  For draftâ€mavrogiannopoulos­â€dtls­â€cid­â€00 and we needed to extend > > the > > DTLS un-authenticated part of the DTLS record header with an > > additional > > field. That works well if this is the only draft ever extending the > > DTLS record header. If not, modification order would be undefined. > > Where is this draft? The published version: https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-cid-00 The latest: https://github.com/thomas-fossati/draft-tls-cid/blob/master/draft-mavrogiannopoulos-tls-cid.md regards, Nikos From nobody Mon Nov 14 23:36:21 2016 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 746C212950D for ; Mon, 14 Nov 2016 23:36:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eNVD_e1o0Mi for ; Mon, 14 Nov 2016 23:36:19 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 2DB311294AD for ; Mon, 14 Nov 2016 23:36:19 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n21so125548944qka.3 for ; Mon, 14 Nov 2016 23:36:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GrtwkdXxuLiexFjeJVh/Ptr63SghjPqWOWue+W0bJr4=; b=Jitr+NTWXRnk1bZ4IoY5JZ7UtbojgHlysi7kz7Nb10u/Wo2me6XNqwO6dehqD03vlc aHtH8kXK0HJbHfqmSaLbsnII/hGFD07YcEkFblyGmtZE6Nu6xH68Z0a+G447N/G2Fd4W Gvi574ojnGgk+BelsXtMk/S8UuHMHuosWPM24IC/sVvM9FI0Lg1fxcU5CGHt7eCHyTiX CbPwfSqZJNCZdyCPi4TH1SEYAdP3b/cwDVtG+Tih2dUbjL+Zxq3hrKzV6czgFWyvud+k vwsMgyPS318Ad2iZl/fYyDZjXBA7PJuPvhUFq3tcveDf4rhr/ShkHBUzuu2FRI+WcnS5 Prdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GrtwkdXxuLiexFjeJVh/Ptr63SghjPqWOWue+W0bJr4=; b=I9pchJyMRAvSuDC3C6g2MRQCW2wpnnjCfeq0p4Ij7vLwrlDKXautLnmtTlADLn6y11 cZ4PND9c9cmDbSdo67yNugyFLiEfRq6GeKK7nbHEkwT65jD32P+dL2+4UIH/JPRckG14 V5WwZ/3wPLM1WqCBzH0YUVUxUb8+/2+kvL4Gt/DoE13rnFoLDX8VhvC1S2h7Fb7N9/WC jv9xUV4245mmwL8uAyq0mGrxp/5yxdaqFrtUhIijvqvMI5j2Kt5AEdu89VFL6Lm/umaL yPCUz8nUp5AI6ruitzdczSUR1WP7Uk3ql+cW8m4T1BBhu3c1edGpGdr4WLGr0Rcnos6t hKPg== X-Gm-Message-State: ABUngvfpj+m5y0exUQ/7kLAbfq8Ur+y6JPqdJHBCA0RyKjV5MARgJ/HwDPTJ95RZ2GyViExXeIms4brM1jEfUw== X-Received: by 10.55.150.131 with SMTP id y125mr20896277qkd.115.1479195378283; Mon, 14 Nov 2016 23:36:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Mon, 14 Nov 2016 23:36:17 -0800 (PST) In-Reply-To: <1479193977.12027.7.camel@redhat.com> References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> <1479193977.12027.7.camel@redhat.com> From: Martin Thomson Date: Tue, 15 Nov 2016 16:36:17 +0900 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 07:36:20 -0000 On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos wrote: > TLDR; the privacy offered by this extension is the same as the privacy > of DTLS over UDP. I disagree. All the privacy considerations of the QUIC connection ID apply here. It would probably pay to follow that discussion. If the intent of this is simply to deal with the NAT rebinding issue, then I think that this is worth doing, but to say that this does not have privacy issues would be overstating the case. From nobody Mon Nov 14 23:39:24 2016 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 B7E671295F6 for ; Mon, 14 Nov 2016 23:39:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z_0F7T-CWWAf for ; Mon, 14 Nov 2016 23:39:21 -0800 (PST) Received: from mail-ua0-x241.google.com (mail-ua0-x241.google.com [IPv6:2607:f8b0:400c:c08::241]) (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 0433112950D for ; Mon, 14 Nov 2016 23:39:21 -0800 (PST) Received: by mail-ua0-x241.google.com with SMTP id 50so8292153uae.2 for ; Mon, 14 Nov 2016 23:39:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CKaYVa3hbH25Btv6zjNDf/kgzocF9/9AtunfdiSYEPo=; b=IZdibpal5U5PUc8/gRwWf4wkmOICualdcQ/f2bFSbu+nAb7wIuV7af5iPbdrsUGdzJ UbWyvaDIDUmvY8fxd9K5z0wsYXO9jg+yEaoOtu0HoN7b6puV2EABIVMKA4h7TafeOYxd lRVItDUwAJ6L1/xYsx1CXRRDN3p5odePEtrGVReuAGaGzJC8sIkrQxBuLQCCnZhLCR5T lRAJSb/5T38X11R4utiLTnvwtG9/uqK1lzBaozG80uWPnx+fB0/2EPo2hG9HMguu1spj 2LLhBG4XQyIGTjsMRgcg4EhNMtHWwOUBh5daLjaFTVq0UPD9epc40QQUyDJI5NpgH+JM qbtQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=CKaYVa3hbH25Btv6zjNDf/kgzocF9/9AtunfdiSYEPo=; b=FJ4/9qnhreNd88s27CgVTJ35ScyT11GUQZeMCzYgfyajP1lhZs8FgG/2exI+k+X8di u/eQTIZ1T07AmBVOt0zuiN5SYz3uaQPPysiZIkUtlZ+oBYk5y6XGM++yh61xUNfGZAhu 0FMx1PrtTMzitYGUFl7MMw79ohxouzyxrx86Bb+1Oq1uOpbafnp836jUOfuz6Zk4N8Zi t4IOWYEePUXYb+ly1F2N6L2cdbmpxZ4opLxPDblZPt1Psa9Z2hn9fGS3o1zl58MPiy2x zLDQrxMNRPZJxvE0DhQ7L9vJ+Md+kmAsY8w4UblUX9vdzGpG86nghLS+/0LcnIFlN7xi DEcQ== X-Gm-Message-State: ABUngve1FBTbmIklTGC0rV9xlS/x/wpJorW2n+3tiwLM0RYH/Oc8azK/o/SXsgn/SZI+Zcvbh7rpRAxVusOr8A== X-Received: by 10.159.33.193 with SMTP id 59mr12032284uac.28.1479195559947; Mon, 14 Nov 2016 23:39:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Mon, 14 Nov 2016 23:39:19 -0800 (PST) In-Reply-To: References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> <1479193977.12027.7.camel@redhat.com> From: Watson Ladd Date: Mon, 14 Nov 2016 23:39:19 -0800 Message-ID: To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 07:39:23 -0000 On Mon, Nov 14, 2016 at 11:36 PM, Martin Thomson wrote: > On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos wrote: >> TLDR; the privacy offered by this extension is the same as the privacy >> of DTLS over UDP. > > I disagree. All the privacy considerations of the QUIC connection ID > apply here. It would probably pay to follow that discussion. > > If the intent of this is simply to deal with the NAT rebinding issue, > then I think that this is worth doing, but to say that this does not > have privacy issues would be overstating the case. I thought we were going to kill NAT with IPv6, but apparently you can't remove bad ideas from the Internet. Another place where connection IDs are needed is with mobile clients: anyone who has used ssh while switching networks knows the pain the lack of a connection ID distinct from the 4-tuple brings. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Man is born free, but everywhere he is in chains". --Rousseau. From nobody Mon Nov 14 23:46:54 2016 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 CF8F4129631 for ; Mon, 14 Nov 2016 23:46:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 KpeSj3c7T7sX for ; Mon, 14 Nov 2016 23:46:51 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 4449C129543 for ; Mon, 14 Nov 2016 23:46:51 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id a10so86672689ywa.3 for ; Mon, 14 Nov 2016 23:46:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5GKY1f+vfawmKm/ZpLqREk0iRVcMamrE/loBfLsCDpU=; b=qL1CugTnNWnsYc2JW3dcekXrjFCTbY4JhBaym0iTEcY6MBoq4sxhTw5jd5bC8S+FF1 21ajXplx7HUVD8eFl8cu8x2Fdb9M0KC3TLOTnkYQp4+ci0AUuGsx0IKbYbeb5A/7yzVM ASqPwK+ADScTKCyrJn4f7jAxSKcb/RekL40TgA+b3vQ/izezc/3a2NhAtBj7MMR1jg+i FDUvPI6/oiZUuTWVp9A0F63TJptUIHGgj1e2Y0t7FaWfXpLsyOIheFmIIJ7Tb8j0QxUJ 0MtxPWmK4KWzzwrXJi0xbqOdAf5D3DnqTXNVlZ8h+kTeH9KktzsHFpOhm7N8i13eiWjH 5ibA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5GKY1f+vfawmKm/ZpLqREk0iRVcMamrE/loBfLsCDpU=; b=UMiVHTtYDQN5eequqQlLPUxsa+JRy/ey9jrGmGLXdXjDWJcDrlgNuDQMg34wOvjcvq irr89dC/uRO3azTnf2MPJF7fJcBIyiZzXG+sh+mA5MCfxy67fT+Hpth6G9X0CHEU1d8+ Bx1bQZhcDhGE4YqNMdNmCm+2vGdOsVPXL6X14BQ2QHqo1WAYxo7fyQvIQD9U16aO5vKs 7VZI6GAdwgqtMX5f+mc3GD7eAV5lyXi0+fp+PgNPRtOS38Q2YJUYXsClJjnSu1fkGmgO 9scWnBsbOcjt17ZgVHG5QYA3amnGzsROBkFSZ3zTSe4vmPvV5ImbIZDLSINVCBeBnMBy N4aQ== X-Gm-Message-State: ABUngvdZqRV50lp7zpPray4vYOK+g3Jxq13PULTY1nzUn6hN/Jdr1acY3Ej84XaraJIrGpg7JF09arlYgZevIQ== X-Received: by 10.13.195.5 with SMTP id f5mr21394598ywd.354.1479196010452; Mon, 14 Nov 2016 23:46:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 14 Nov 2016 23:46:10 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 15 Nov 2016 16:46:10 +0900 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=001a114d5fd6c1fff905415228db Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Point validation in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 07:46:53 -0000 --001a114d5fd6c1fff905415228db Content-Type: text/plain; charset=UTF-8 On Tue, Nov 15, 2016 at 4:16 PM, Watson Ladd wrote: > Hello, > > There has been a lot of chatter on Gitub about point validation. I think > it's important to note that in TLS 1.3 the Triple Handshake variants > enabled by small subgroup attacks are no longer a threat: the issue is > reuse of ephemeral Diffie-Hellman exponents, resulting in compromise of > what is effectively a long-term key. > > I would want a belt and suspenders approach: no use of ephemeral > exponents, > Just to clarify, you mean "no reuse", right? -Ekr > and validation that points are on the curve. Order validation is > unnecessary as the cofactor is small: in cases where it is not the curve > probably shouldn't be used without a good reason, and I can't think of any. > > I know one implementation does keep ephemeral exponents indefinitely. This > implementation also validates orders, which equals the expense of not > regenerating ephemeral exponents. > > Sincerely, > Watson > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114d5fd6c1fff905415228db Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 15, 2016 at 4:16 PM, Watson Ladd <watsonbladd@gmail.co= m> wrote:
= Hello,

There has been a lot of chatter on Gitub about po= int validation. I think it's important to note that in TLS 1.3 the Trip= le Handshake variants enabled by small subgroup attacks are no longer a thr= eat: the issue is reuse of ephemeral Diffie-Hellman exponents, resulting in= compromise of what is effectively a long-term key.

I would want a belt and suspenders approach: no use of ephemeral exponent= s,

Just to clarify, you mean &= quot;no reuse", right?

-Ekr
=C2=A0<= /div>
and validation th= at points are on the curve. Order validation is unnecessary as the cofactor= is small: in cases where it is not the curve probably shouldn't be use= d without a good reason, and I can't think of any.

=
I know one implementation does keep ephemeral exponents indefinitely. = This implementation also validates orders, which equals the expense of not = regenerating ephemeral exponents.=C2=A0

Sincerely,=
Watson

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a114d5fd6c1fff905415228db-- From nobody Tue Nov 15 00:02:33 2016 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 A29A4129A25 for ; Tue, 15 Nov 2016 00:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 225skYDJ-npz for ; Tue, 15 Nov 2016 00:02:31 -0800 (PST) Received: from mail-pg0-x22e.google.com (mail-pg0-x22e.google.com [IPv6:2607:f8b0:400e:c05::22e]) (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 091FC129631 for ; Tue, 15 Nov 2016 00:02:31 -0800 (PST) Received: by mail-pg0-x22e.google.com with SMTP id p66so64104190pga.2 for ; Tue, 15 Nov 2016 00:02:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vaf7RfAnoN0zJe3tQHsRFgDeJdKvSc5wYaWxp8w+ukM=; b=hJR3zU4HrKoRqAqDG+ScjitJJ4dZ8NEmVx7iXYN/Q7Y/yNoJytlqYU7Psx0Xu0yEBt J286wDKKGbwurBnZPmlFyuwr2QVuYTEssDbD3ATTGlNBJ0X87MUilIPDKXlUMxN5jR7e +UNWp1rOkjuIIOdBpxfXNh19jUe9v8PkS7g34WfGT9imp0UU27accZ/eEStN5aaOaDyf 9o6AT/49PvK+kuUlUHg6MNDYGnVk5FFMJTEZx5PiJo81jTc7tq7dRAkfhrFRLfXGC7CM vKb3F6domEwc3TJqUB/xHpSWgEWqmeRSObv6S40+9nHAzpbulzyNV9EYTsHzcGhrJM5C F6AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vaf7RfAnoN0zJe3tQHsRFgDeJdKvSc5wYaWxp8w+ukM=; b=PfPkUyKE48+82I8JxyXEOA5Q3bF21trdyoEuX/Mv0rCAETHYxocHqs2ZMvFw54Fkk/ CaChFIf4Enu3PUcUbqOve5aMc34IZ/fma34kloU6sMHQUdC9vV2Ae78oMHvdWQ/zWS/Q WmD80ePaDOnYuhjSAiMZfvx/sJX4ad2Ja5sauiWe73QNWsTgB2wQ/zDdrM+ijawR0fgi JLiJpagvSWKUt89RrsFLfKlnFTlMe5sZPGE5Z6Ume+aJi4K1s4ZsF3Oo0hlkTbgI6+DZ OZuCteqbOM2r8AzpPt/D9njGyuFUAOB8nfY92UupWTKxSgIvOTnkZtMnQLRFY3lHTObo yCow== X-Gm-Message-State: ABUngvdl7t6Gi2Za+VtJIovrAlsEw0DrERmLR76QThCmZpXmHRRzugMIPI8mDqZ1DDSFGA== X-Received: by 10.99.112.13 with SMTP id l13mr7383172pgc.7.1479196950616; Tue, 15 Nov 2016 00:02:30 -0800 (PST) Received: from t2001067c03700128c9d54d1e685141e0.v6.meeting.ietf.org ([2001:67c:370:128:c9d5:4d1e:6851:41e0]) by smtp.gmail.com with ESMTPSA id tk5sm8369876pab.21.2016.11.15.00.02.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 00:02:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: Date: Tue, 15 Nov 2016 17:02:24 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4D79E074-6231-4CDD-88A0-2E8EBEA1BCA5@gmail.com> References: To: Watson Ladd X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Point validation in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 08:02:33 -0000 I think the performance enhancement (in terms of handshakes per second) = that you get by reusing ephemeral keys is so great, that we have to = assume people will do it. You don=E2=80=99t have to keep the keys = indefinitely. It=E2=80=99s fine to generate a new key every second or = ten seconds or so. Which makes running the point validation all the more important. Yoav > On 15 Nov 2016, at 16:16, Watson Ladd wrote: >=20 > Hello, >=20 > There has been a lot of chatter on Gitub about point validation. I = think it's important to note that in TLS 1.3 the Triple Handshake = variants enabled by small subgroup attacks are no longer a threat: the = issue is reuse of ephemeral Diffie-Hellman exponents, resulting in = compromise of what is effectively a long-term key. >=20 > I would want a belt and suspenders approach: no use of ephemeral = exponents, and validation that points are on the curve. Order validation = is unnecessary as the cofactor is small: in cases where it is not the = curve probably shouldn't be used without a good reason, and I can't = think of any. >=20 > I know one implementation does keep ephemeral exponents indefinitely. = This implementation also validates orders, which equals the expense of = not regenerating ephemeral exponents.=20 >=20 > Sincerely, > Watson > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Nov 15 00:35:02 2016 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 B889D12964D for ; Tue, 15 Nov 2016 00:34:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gNop5rYg7fEJ for ; Tue, 15 Nov 2016 00:34:55 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 875F21296CE for ; Tue, 15 Nov 2016 00:34:55 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 2CF1BEEF47D0B; Tue, 15 Nov 2016 08:34:52 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAF8YpkC006220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2016 08:34:53 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uAF8YoiU028053 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2016 09:34:51 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.241]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Tue, 15 Nov 2016 09:34:50 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Martin Thomson , Nikos Mavrogiannopoulos Thread-Topic: [TLS] extending the un-authenticated DTLS header Thread-Index: AQHSPxshT8IA2htqqEmXxQo4G0FPBg== Date: Tue, 15 Nov 2016 08:34:50 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-ID: <8334356BF2B92B49B4846C9786B0024E@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 08:34:58 -0000 On 15/11/2016 07:36, "TLS on behalf of Martin Thomson" wrote: >On 15 November 2016 at 16:12, Nikos Mavrogiannopoulos >wrote: >> TLDR; the privacy offered by this extension is the same as the privacy >> of DTLS over UDP. > >I disagree. All the privacy considerations of the QUIC connection ID >apply here. It would probably pay to follow that discussion. > >If the intent of this is simply to deal with the NAT rebinding issue, >then I think that this is worth doing, but to say that this does not >have privacy issues would be overstating the case. I agree. We had previous discussion on and off list about this and we took Stephen's point to look at ways to make this identifier privacy friendly. The draft proposes two ways to allocate the identifier (see 3rd para of https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1): 1. Server decides unilaterally a value that is fixed for the duration of the session (SecAssocType.fixed); 2. Server and Client agree on a sequence of values generated using HOTP [RFC 4226] seeded by the session shared secret (SecAssocType.hotp); Client shifts to the next value when needed (e.g. on transport handover). At first this might not look particularly elegant, but there are good reasons for having both methods. From nobody Tue Nov 15 01:10:08 2016 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 8E8B91295EC for ; Tue, 15 Nov 2016 01:10:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C6-d0bl2By-E for ; Tue, 15 Nov 2016 01:10:06 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 CB8A5129450 for ; Tue, 15 Nov 2016 01:10:05 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id w33so64195922qtc.3 for ; Tue, 15 Nov 2016 01:10:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vXA+wdJ/30q3WtOHIdNRWku7xRtjtZdBrGaJtVHQ9pI=; b=YSvYB2psmb9x0qg4SSCyhN3uZj4npmDai+3FifVb8HWG9FY9DY//5G3jH7tW9YHxWe SpasUGmpKD0fdbCGxcocnltTnBespHBBHeYD7v2nU6jWArDe/JTQ5jyHsHtC6WgdbSEt vXllwXNqCZ+1KY5hRhljBVbSI4ekUo0A2PQDUihK+FUW/+iER2G0kNpcp6w56f/nm1FR 8cw/1TDi71vVYqkr/BCRrAlKB7glTnmrzTCr3vfF1Tml2XeIOIcK8u142sgtpu3PkbIq AF8D4BqrI2N94K1xSOg0NL6Eog27JXeGMIz8AK1s94HQr0CTpMkEGuWfAarG9gEEL1rx 295Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vXA+wdJ/30q3WtOHIdNRWku7xRtjtZdBrGaJtVHQ9pI=; b=dhFEga0YhgiNx5GIBQv/6Vo1FFqlCYdps4vNNpoJshM68TTtEHJ/0iOZjwmvId4/hj HW7af1yzYQ6ezGIYWhBgEoUChfyOHimfjP6z9oFp+sT9uru8X72nna6iJGW0IHYzkzsN doVPC06E5O2PniAojlmiViCw5V8Gi9WiGl098KwVeQzU0/2gSzNDc5U7rO40Dwrcqq+O M9Jmys0GW/aYZwGxdKRFVvGtQjIh6wocwApLB0ROXVecBZJoszgeNIZlBxBH/NvBJ0Gd l2IL/EJivU5tkjqcAFVH52IMxd183DjR0eJjSWgMCRWiePDOA/3VPQLfcrWYTAbZLUII 5Frg== X-Gm-Message-State: ABUngvd+K828TI+t4TTK/vTKA30kQ3fj9WqnOStjBAa2eI0jhnvNpcgVajrc3NgJb3QWCZSsVLj5Q4Fzwn2WFg== X-Received: by 10.200.44.27 with SMTP id d27mr10551706qta.278.1479201004902; Tue, 15 Nov 2016 01:10:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 15 Nov 2016 01:10:04 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Tue, 15 Nov 2016 18:10:04 +0900 Message-ID: To: "Fossati, Thomas (Nokia - GB)" Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 09:10:07 -0000 On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB) wrote: > The draft proposes two ways to allocate the identifier (see 3rd para of > https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1): > 1. Server decides unilaterally a value that is fixed for the duration of > the session (SecAssocType.fixed); > 2. Server and Client agree on a sequence of values generated using HOTP > [RFC 4226] seeded by the session shared secret (SecAssocType.hotp); Client > shifts to the next value when needed (e.g. on transport handover). > > > At first this might not look particularly elegant, but there are good > reasons for having both methods. I'm not seeing quite enough information here to implement this. How does a server know which of the many HOTP keys it has are in use? Surely you can't use the same HOTP key with every client. From nobody Tue Nov 15 01:18:45 2016 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 D1B0F129A30 for ; Tue, 15 Nov 2016 01:18:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.419 X-Spam-Level: X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 cXEZypTOcu1v for ; Tue, 15 Nov 2016 01:18:42 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 446BE1293DF for ; Tue, 15 Nov 2016 01:18:42 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id EDBE3624B3; Tue, 15 Nov 2016 09:11:39 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.106]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAF9BbnI032449 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Nov 2016 04:11:38 -0500 Message-ID: <1479201097.12027.10.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Martin Thomson , "Fossati, Thomas (Nokia - GB)" Date: Tue, 15 Nov 2016 10:11:37 +0100 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 15 Nov 2016 09:11:40 +0000 (UTC) Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 09:18:44 -0000 On Tue, 2016-11-15 at 18:10 +0900, Martin Thomson wrote: > On 15 November 2016 at 17:34, Fossati, Thomas (Nokia - GB) > wrote: > > > > The draft proposes two ways to allocate the identifier (see 3rd > > para of > > https://thomas-fossati.github.io/draft-tls-cid/#rfc.section.1): > > 1. Server decides unilaterally a value that is fixed for the > > duration of > > the session (SecAssocType.fixed); > > 2. Server and Client agree on a sequence of values generated using > > HOTP > > [RFC 4226] seeded by the session shared secret (SecAssocType.hotp); > > Client > > shifts to the next value when needed (e.g. on transport handover). > > > > > > At first this might not look particularly elegant, but there are > > good > > reasons for having both methods. > > I'm not seeing quite enough information here to implement this.  How > does a server know which of the many HOTP keys it has are in use? > Surely you can't use the same HOTP key with every client. Not sure I understand the question, but I'd suggest to read the text on generating the hotp keys. regards, Nikos From nobody Tue Nov 15 01:20:07 2016 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 CEC0E129A30 for ; Tue, 15 Nov 2016 01:20:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jkz6NH1fDUAV for ; Tue, 15 Nov 2016 01:20:05 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 9043F1296CD for ; Tue, 15 Nov 2016 01:20:05 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id n204so127993582qke.2 for ; Tue, 15 Nov 2016 01:20:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=klgvfKCSveQlRGhx0fj8CMXC/jxH8kkmk83TI/bfgGo=; b=hYScunebJHfwV/1i11/LZ13+5t8qA3+oEgOpRnGaaiDkJiRJBBid8wtpqEIsMrVJjb 5B6jBu1vKpy7ra0ZjhZk4ivFlz05aHN6ZceKTj4pdxryJ211qiM3LWaOR//kAh0JnvS/ kR1R6jAJcEunSjoVMk0tK+QYf9A+z/+DFwMqAXrD5eLFO38Fqj02jwgP1k8DYI8olmG9 E8/IISVhmD5Fp5q7OSnO0tTbEmh8HQWRjBJz6gcARMBvkDl5gIQ85DsZEzHw2gClmfn9 nw5NTjHm8LbnLVmvIG9M4qpYrXqDFAEESyrv+Zp+gmK9FcgsqI36WoHN5NkKtqMQRwXU FqiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=klgvfKCSveQlRGhx0fj8CMXC/jxH8kkmk83TI/bfgGo=; b=b+lQBOGTwidxKxU8pvM3h40F4fTihmCgSHf3RP6/COXduwO9nAZ8a81Q7t+dPUmJXs d1MEHgxHbgYDdDya1qQV1WZCiCAw3IsIAGefvTZ6ra0TM4IwJCuLU75QUBHGNdmBj6rd P5L0uGPwJb+YgLPhX1N60mkIH8YOV4VNfaaUgAMeYTpkhjQJ8ykCPadgPfGusQVb519V AcIdd32Uj9lqU7BFqKEZ+kRZiEnce7zq2zwkjT5JRJ+UKCzgBnP+nj3m//DZV0M7fn+i dMVZNw1Y2LjNv3IdiCw0NqlaGGE1z0w4N5yzbCqyBjJnWMXsd8+DIFwG1tpXcXJr+7tQ jZSQ== X-Gm-Message-State: ABUngvdTjGg8vE+9lCECFovKrYspToUakqv9+raBcr+GT87+VfJbxjjw788C1Jd5wUd2FwmLdHYU/fQjDSGtlw== X-Received: by 10.55.99.141 with SMTP id x135mr20578382qkb.147.1479201604656; Tue, 15 Nov 2016 01:20:04 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 15 Nov 2016 01:20:04 -0800 (PST) In-Reply-To: <1479201097.12027.10.camel@redhat.com> References: <1479201097.12027.10.camel@redhat.com> From: Martin Thomson Date: Tue, 15 Nov 2016 18:20:04 +0900 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 09:20:07 -0000 On 15 November 2016 at 18:11, Nikos Mavrogiannopoulos wrote: >> I'm not seeing quite enough information here to implement this. How >> does a server know which of the many HOTP keys it has are in use? >> Surely you can't use the same HOTP key with every client. > > Not sure I understand the question, but I'd suggest to read the text on > generating the hotp keys. OK, I re-read it. It wasn't particularly clear from the overview. But you generate the HOTP based on an exporter. That means that the server has no control over the contents of the CID, direct or otherwise. This means that you can guarantee privacy, but it forces the server to do an exhaustive search of all of its active connections (that is, O(N)) when it gets a 5-tuple mismatch. There are probably designs that don't have this property. For instance, the server could propose an identifier or set of identifiers. That means that a bad server could willfully break the privacy property, but it also means that it doesn't have the scaling issues. From nobody Tue Nov 15 01:30:54 2016 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 C8C94129A30 for ; Tue, 15 Nov 2016 01:30:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.402 X-Spam-Level: X-Spam-Status: No, score=-6.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 B74TmyDq6kQm for ; Tue, 15 Nov 2016 01:30:51 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D23129450 for ; Tue, 15 Nov 2016 01:30:50 -0800 (PST) Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 5E5351C57C25B; Tue, 15 Nov 2016 09:30:45 +0000 (GMT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAF9Uki3002695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2016 09:30:47 GMT Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id uAF9Tex9008610 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2016 10:30:46 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.241]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0301.000; Tue, 15 Nov 2016 10:30:35 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Martin Thomson , Nikos Mavrogiannopoulos Thread-Topic: [ALU] Re: [TLS] extending the un-authenticated DTLS header Thread-Index: AQHSPyBmoEWQi/eZf0uXxBxfDzXt66DZs+EAgAAC6AA= Date: Tue, 15 Nov 2016 09:30:35 +0000 Message-ID: References: <1479201097.12027.10.camel@redhat.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <8A3EA336EA0CD4448EBE061B18A8F456@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 09:30:53 -0000 On 15/11/2016 09:20, "TLS on behalf of Martin Thomson" wrote: >This means that you can guarantee privacy, but it forces >the server to do an exhaustive search of all of its active connections >(that is, O(N)) when it gets a 5-tuple mismatch. I don't think I follow. You'd use CID as primary key to index your security contexts. So, regardless your 5-tuple matches or not you'd do your O(1) lookup in the CID table and find the associated security context. From nobody Tue Nov 15 02:12:51 2016 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 C1A131297AC for ; Tue, 15 Nov 2016 02:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ij7F3dCi15A2 for ; Tue, 15 Nov 2016 02:12:42 -0800 (PST) Received: from mail-qk0-x241.google.com (mail-qk0-x241.google.com [IPv6:2607:f8b0:400d:c09::241]) (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 7E2A5129A31 for ; Tue, 15 Nov 2016 02:12:42 -0800 (PST) Received: by mail-qk0-x241.google.com with SMTP id n204so15611823qke.2 for ; Tue, 15 Nov 2016 02:12:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fswvbbEsii/PdbyefGAD7kdAlGgtbgJFM66GyuIOxkY=; b=HaeRlDBtxVizmYmyaIl5wfethVXQbeKv7eDLMYY45iC7aGy5ePMsr94pV+OfjiNgWZ o8rIETNRAWPcgJ7B3j+bxvYaeZUU9CfSnXKPK5pWrUmd8khoBjXkjJ23dOHEjcPc+Du7 BX9G2Q+7mU8ir5aG1bB7S4euyaZdRAih2tmiT8EQr23Rv2Auilc/1JJZE6/Dm4XFs6OW 95r1scw801Dh67MGz/vBEU2sKfRejx/qCU6L9q74qXy1vVat4rottAngMCY4Rb3p9Pbi JfJZrs+dQB8rmhl74cvnlYvmjuXz/dtOziGkjnSHxXP49LYuWyMEUx6hw6lQP44NzQu/ I48g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fswvbbEsii/PdbyefGAD7kdAlGgtbgJFM66GyuIOxkY=; b=CmrX2KIWXxx5H4ryDGKBPR/DAI8bO/Gux0L/1rDybPb/eIN6IuhTZRlRsH9MpDLynb h/N+6XyxisAQANIN8A4Nuo/XBvrw0MJNs3gAAASqZDhIrLbfO+WbHcLqYGlbyXtojufC Zpe4esT4GtWM+4V/Kj7+M6VeEj79k2yWZ4UEHqzgH3mQPKmvGqV85vLN5q+VQ1CO86Is IhO+FzAYygZNoyXqtz2rwblhRGU4iIbZk0rulTGC07TVmFQUM5lUi9OrzRPPnbniQWC/ 2FKO7el1x4Fe+lAKLW/RVg2rMBpuL+oqOzmKo1n8m0aclUkbX4YKMouq8kvNxIk5ZoO5 svqg== X-Gm-Message-State: ABUngvchnwkJYxehsqBjbmLTgLpKGpHCOvPp4H88Dwp/844gP2ouYdOAMAZAtwlRb1YoiF6x2ON6RSzBq+P5Xg== X-Received: by 10.55.12.2 with SMTP id 2mr21354555qkm.68.1479204761620; Tue, 15 Nov 2016 02:12:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Tue, 15 Nov 2016 02:12:40 -0800 (PST) Received: by 10.140.85.7 with HTTP; Tue, 15 Nov 2016 02:12:40 -0800 (PST) In-Reply-To: References: <1479201097.12027.10.camel@redhat.com> From: Martin Thomson Date: Tue, 15 Nov 2016 19:12:40 +0900 Message-ID: To: "Thomas Fossati (Nokia - GB)" Content-Type: multipart/alternative; boundary=001a114c5c9e5dd879054154329a Archived-At: Cc: Hannes Tschofenig , tls@ietf.org Subject: Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 10:12:49 -0000 --001a114c5c9e5dd879054154329a Content-Type: text/plain; charset=UTF-8 Okay, so you are saying that every packet has the same number? On 15 Nov 2016 6:30 PM, "Fossati, Thomas (Nokia - GB)" < thomas.fossati@nokia.com> wrote: > On 15/11/2016 09:20, "TLS on behalf of Martin Thomson" > wrote: > >This means that you can guarantee privacy, but it forces > >the server to do an exhaustive search of all of its active connections > >(that is, O(N)) when it gets a 5-tuple mismatch. > > I don't think I follow. You'd use CID as primary key to index your > security contexts. So, regardless your 5-tuple matches or not you'd do > your O(1) lookup in the CID table and find the associated security context. > > --001a114c5c9e5dd879054154329a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Okay, so you are saying that every packet has the same numbe= r?


On 15 Nov 2016 6:= 30 PM, "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com> wrote:
On 15/11/2016 09:20, "TLS on = behalf of Martin Thomson"
<tls-bounces@ietf.org on beh= alf of martin.thomson@gmail.com= > wrote:
>This means that you can guarantee privacy, but it forces
>the server to do an exhaustive search of all of its active connections<= br> >(that is, O(N)) when it gets a 5-tuple mismatch.

I don't think I follow.=C2=A0 You'd use CID as primary key to index= your
security contexts.=C2=A0 So, regardless your 5-tuple matches or not you'= ;d do
your O(1) lookup in the CID table and find the associated security context.=

--001a114c5c9e5dd879054154329a-- From nobody Tue Nov 15 02:21:54 2016 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 5DD9A129A6E for ; Tue, 15 Nov 2016 02:21:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 t9_3v9kroseA for ; Tue, 15 Nov 2016 02:21:47 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9D8129A31 for ; Tue, 15 Nov 2016 02:21:47 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 50DCFD3916F69; Tue, 15 Nov 2016 10:21:41 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAFALgSc000661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 15 Nov 2016 10:21:42 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uAFALfXR021426 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 15 Nov 2016 11:21:41 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.241]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Tue, 15 Nov 2016 11:21:41 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Martin Thomson , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [TLS] extending the un-authenticated DTLS header Thread-Index: AQHSPyoNbF5RMnM5zECGeIwdLn0saw== Date: Tue, 15 Nov 2016 10:21:40 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [135.239.27.38] Content-Type: multipart/alternative; boundary="_000_D450906775EE7thomasfossatialcatellucentcom_" MIME-Version: 1.0 Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 10:21:49 -0000 --_000_D450906775EE7thomasfossatialcatellucentcom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Sort of. Client uses one HOTP value from the sequence at a time, until it = sees fit =97 for example, until it's on the same network attachment. When attachment changes (and its transport identifiers with it), before sen= ding a new packet, it picks the next HOTP and sticks it in the record. When Server sees this, it switches CID accordingly. From: Martin Thomson > Date: Tuesday, 15 November 2016 10:12 To: "Fossati, Thomas (Nokia - GB)" > Cc: Nikos Mavrogiannopoulos >, "tls= @ietf.org" >, Hannes= Tschofenig > Subject: Re: [ALU] Re: [TLS] extending the un-authenticated DTLS header Okay, so you are saying that every packet has the same number? On 15 Nov 2016 6:30 PM, "Fossati, Thomas (Nokia - GB)" > wrote: On 15/11/2016 09:20, "TLS on behalf of Martin Thomson" on behalf of martin.thom= son@gmail.com> wrote: >This means that you can guarantee privacy, but it forces >the server to do an exhaustive search of all of its active connections >(that is, O(N)) when it gets a 5-tuple mismatch. I don't think I follow. You'd use CID as primary key to index your security contexts. So, regardless your 5-tuple matches or not you'd do your O(1) lookup in the CID table and find the associated security context. --_000_D450906775EE7thomasfossatialcatellucentcom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <5FF5BE0374E38043A28199453F69F150@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable
Sort of.  Client uses one HOTP value from the sequence at a time,= until it sees fit =97 for example, until it's on the same network attachme= nt.

When attachment changes (and its transport identifiers with it), befor= e sending a new packet, it picks the next HOTP and sticks it in the record.=
When Server sees this, it switches CID accordingly.

From: Martin Thomson <martin.thomson@gmail.com>
Date: Tuesday, 15 November 2016 10:= 12
To: "Fossati, Thomas (Nokia - = GB)" <thomas.fossati@no= kia.com>
Cc: Nikos Mavrogiannopoulos <nmav@redhat.com>, "tls@ietf.org" <tls@ietf.org>, Hannes Tschofenig <Hannes.Tschofenig@arm.com>
Subject: Re: [ALU] Re: [TLS] extend= ing the un-authenticated DTLS header

Okay, so you are saying that every packet has the same numbe= r?


On 15 Nov 2016 6:30 PM, "Fossati, Thomas (N= okia - GB)" <thomas.fos= sati@nokia.com> wrote:
On 15/11/2016 09:20, "TLS on behalf of Martin Thomson"
<tls-bounces@ietf.org on beh= alf of martin.thomson@gmail.com> wrote:
>This means that you can guarantee privacy, but it forces
>the server to do an exhaustive search of all of its active connections<= br> >(that is, O(N)) when it gets a 5-tuple mismatch.

I don't think I follow.  You'd use CID as primary key to index your security contexts.  So, regardless your 5-tuple matches or not you'd d= o
your O(1) lookup in the CID table and find the associated security context.=

--_000_D450906775EE7thomasfossatialcatellucentcom_-- From nobody Tue Nov 15 03:53:22 2016 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 730CB124281 for ; Tue, 15 Nov 2016 03:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.419 X-Spam-Level: X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 xBE8N8lH5jXv for ; Tue, 15 Nov 2016 03:53:18 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 556311295A3 for ; Tue, 15 Nov 2016 03:53:18 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id CF02261BB4; Tue, 15 Nov 2016 11:53:17 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAFBrGrR021716 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 15 Nov 2016 06:53:17 -0500 From: Hubert Kario To: tls@ietf.org Date: Tue, 15 Nov 2016 12:53:15 +0100 Message-ID: <3543263.QZeSEPR1jY@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.6-201.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: <201610312019.15918.davemgarrett@gmail.com> References: <201610312019.15918.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4598304.q0ExPyyMog"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Tue, 15 Nov 2016 11:53:18 +0000 (UTC) Archived-At: Subject: Re: [TLS] supported_versions question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 11:53:21 -0000 --nextPart4598304.q0ExPyyMog Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Monday, 31 October 2016 20:19:15 CET Dave Garrett wrote: > On Monday, October 31, 2016 08:05:59 pm Matt Caswell wrote: > > On 31/10/16 23:53, Dave Garrett wrote: > > >> I came up with some alternative wording that I think captures the > > >> discussion: > > >>=20 > > >> https://github.com/tlswg/tls13-spec/pull/748 > > >=20 > > > I see no reason to require servers to validate the legacy version val= ue. > > > That's just excess complexity. If the extension is there, then it > > > should take absolute precedence. If not, use the old system. Nothing > > > will have a higher value there except old probers.>=20 > > If legacy_version =3D=3D 0x0302 (TLS1.1), but highest supported_version= is > > 0x0303 (TLS1.2) - or vice versa, which client_version should be used > > in an RSA key exchange calculation? >=20 > Why would this ever happen? What client is offering to support TLS 1.1 via > the ClientHello field but offers only TLS 1.2 via the TLS 1.3 extension? > This is a very contrived implementation error; if you need to account for > it, abort the connection with an error. As to the vice versa, dropping > 1.0/1.1 support from the extension avoids that. could be a result of fallback dance And I think it should be treated the same way signature_algorithms are -=20 inapplicable to TLS1.1 and lower - thus ignore completely =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart4598304.q0ExPyyMog Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYKvcrAAoJEJKo0bgB0vX1uQMP/Ri1z2kWf/wmZuemS343fsvU Ua2WKWQzh/5GuZS4DvWLSVYYBobNIhrBfMTYU/Ty3rBesQpCGLJZgJS8wbBE0J2X toU5ffhCucZZbS45jCabciLGVJxP8nmddEz6TH5a7DoE1Hx9cj0taxzn3ofZlY3d 8F8qfoMfE98EJ8h/Z+PsaiD0ALuKu+D6LkGYDEd2XuLDkNkNh5gZ1lVBuW+mHI1i NM9Ph40aqZeco+ZSeGsc93Z5Ee1HfF475Y44HkDvBdOoW0yPSV8rzvZ70vgRQ5C5 +/Qxh48AOZY+QqQVFgmucxEvbZtZzfXlvE5DiRd/m4Isy+zKDn8NxNXQlLW2hCnF JKID0+DAVtQTBoRejarHEvl99KfijQW9+WXWy292IPI3GLEvyGmVyVmfoZRwmShd /MYXkmaH/vmvGecfhH40M2yTANCFXqaeEspq2gbSS0ZqAhns5OPU2v+ZnfSzf3Zx 0UxWVb8ZZfq1FDfV5C5eEBA5giwOmOaZkanZ+iE+4zxdRE//g/N2MB7bLdgTyco9 +FfanTDNDPD0qK1+DXrpLFISGsQE2qJ1GrUpephJO4bqNKineIFNrprXQTTfHn/n kSSRsS3p9MBLDpAUPUp+22AiNyfvr6cMFVx/KYCrwuoMOdT9kkC7gyQIwm5Il5Kj EXwKtg+9AglNhkhnmsEV =EJDq -----END PGP SIGNATURE----- --nextPart4598304.q0ExPyyMog-- From nobody Tue Nov 15 07:36:05 2016 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 EFAD11294EB for ; Tue, 15 Nov 2016 07:36:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 C9eYxXdq8Y7d for ; Tue, 15 Nov 2016 07:36:01 -0800 (PST) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 4D8EB1294C9 for ; Tue, 15 Nov 2016 07:36:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id BF9FE12BD5; Tue, 15 Nov 2016 17:35:59 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id ROY-Q_mI3_-q; Tue, 15 Nov 2016 17:35:59 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 7770CC4; Tue, 15 Nov 2016 17:35:59 +0200 (EET) Date: Tue, 15 Nov 2016 17:35:55 +0200 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20161115153555.GA7882@LK-Perkele-V2.elisa-laajakaista.fi> References: <4D79E074-6231-4CDD-88A0-2E8EBEA1BCA5@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4D79E074-6231-4CDD-88A0-2E8EBEA1BCA5@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Point validation in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 15 Nov 2016 15:36:04 -0000 On Tue, Nov 15, 2016 at 05:02:24PM +0900, Yoav Nir wrote: > I think the performance enhancement (in terms of handshakes per second) > that you get by reusing ephemeral keys is so great, that we have to > assume people will do it. You don’t have to keep the keys indefinitely. > It’s fine to generate a new key every second or ten seconds or so. > > Which makes running the point validation all the more important. There's two main reasons for point validation: 1) Preventing leaking of the secret exponent. 2) Preventing key collisions from low-order points. TLS 1.3 isn't vulernable to 2) like TLS 1.2 and below are (without EMS). X25519/X448 have been explicitly designed to resist 1). If you want to prevent using low-order points for some reason, there is a handy trick: Check if the output of X25519/X448 is all zeroes or not, and abort if it is. -Ilari From nobody Tue Nov 15 17:11:44 2016 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 E9AD9129544 for ; Tue, 15 Nov 2016 17:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 yrIrz4skgR35 for ; Tue, 15 Nov 2016 17:11:40 -0800 (PST) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (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 D3AF5129650 for ; Tue, 15 Nov 2016 17:11:26 -0800 (PST) Received: by mail-oi0-x231.google.com with SMTP id 128so45204381oih.0 for ; Tue, 15 Nov 2016 17:11:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=2XP+zv/z7cyoWZ7NDYMCU9zP4oVMSqYWfOckiULntWU=; b=cDutlwLjC6/FyrsfI0WJ05B2AgcqsaL1cNIS2JE26nXlLmrRYPyv9ONuq7frctnc+F TD1O2U9mrPv+Hm56ZssCx48f4LYVbFy8XnxJxvnbNfAGcKpwgtYa8Q4Q1gCiQcIQfD89 qNfQ10eDuxnnPdEbCS9vFU3DVWpvUrg+566NY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=2XP+zv/z7cyoWZ7NDYMCU9zP4oVMSqYWfOckiULntWU=; b=hbyJ0Kw5a4VhCNoqbDnjn/LqvPr7eVsM6UpbVo51aWXRrlV749HX/yEj1aG6C4yPob IksXeft5Rif4mTReHvOzmBWQPAYe2//LY8CoGLt49MLz+eJbSUwLj2Xnri6ACTPJ2uep NdBxrZr12I2MUfQgEP+Us4PgFL6uXjdgLlEkDU2BKY+Pu5dgq6nv63avcGudVLS2wNtM ZD9YzH/JIchLooB3NDQg721HREAq9U7A+qQoK+JB4q6QsPh6UOZYVM9RlxmvqoDe3sHv uahpqTX6eNsrv/2U/7GwxoKJA+eWW34uM7sfnNNTj8gMEo1Hz96yzt7SaUSem3A1Rrfb DOtQ== X-Gm-Message-State: AKaTC00sT7EaqbfEq+GAIhpxapm/N6R8OphgabgJCmhVtBwZP2/+RARVSmycn+20XOe8Vw== X-Received: by 10.157.63.143 with SMTP id r15mr390857otc.199.1479258686136; Tue, 15 Nov 2016 17:11:26 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:e9ab:fa4e:d021:8fe4? ([2001:67c:370:128:e9ab:fa4e:d021:8fe4]) by smtp.gmail.com with ESMTPSA id e184sm9853262oig.7.2016.11.15.17.11.25 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 15 Nov 2016 17:11:25 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: Date: Wed, 16 Nov 2016 10:10:59 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <7F6ED934-C75A-498E-96F3-B0A4E1913A3E@sn3rd.com> References: To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] housekeeping: uplift RFC 5289 to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 16 Nov 2016 01:11:43 -0000 Note that Russ pointed out during the meeting that even though we can = use this process a new RFC # will be minted at the end of the process. spt > On Nov 14, 2016, at 10:36, Sean Turner wrote: >=20 > This email addresses the "Uplifting=E2=80=9D bullet on slide 6 of the = chair slides = (https://www.ietf.org/proceedings/97/slides/slides-97-tls-tls-wg-chair-sli= des-00.pdf); this is entirely procedural (i.e., there=E2=80=99s really = no technical ). >=20 > The cipher suite registry's new "WG recommended=E2=80=9D column's = =E2=80=9CY" values are being populated with cipher suites that are on = standards track. The notable exceptions are the EC-based AES-GCM = ciphers defined in RFC 5289, which is an informational RFC. This point = is buried in an earlier version of draft-ietf-tls-tls13 and now in the = soon to be draft-ietf-tls-iana-registry-updates (was = draft-sandj-tls-iana-registry-updates); the complete list of the pet-TLS = 1.3 suites can be found here: = https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01#secti= on-6. >=20 > We can uplift RFC 5289 to PS from Informational with what essentially = amounts to an IETF LC; we don't need a new draft (there's no errata). = We want to know if there are any objections to starting this process = please post a message to the list by November 21st if you object (and = why). >=20 > Please note the following: >=20 > - This "action" is similar to what we're doing with 4492bis (it too = is being moved to standards track) it's just that we can use this other = process. >=20 > - RFC 7525, which was published through the UTA WG and is a BCP btw, = already 2119-RECOMMENDs the ciphers. >=20 > - RFC 7540 (aka HTTP/2) MUSTs one of the RFC 5289 cipher suites. >=20 > spt From nobody Tue Nov 15 17:49:58 2016 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 56D0D129552 for ; Tue, 15 Nov 2016 17:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zv73WRRa9mds for ; Tue, 15 Nov 2016 17:49:54 -0800 (PST) Received: from mail-pf0-x22d.google.com (mail-pf0-x22d.google.com [IPv6:2607:f8b0:400e:c00::22d]) (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 468EC129411 for ; Tue, 15 Nov 2016 17:49:54 -0800 (PST) Received: by mail-pf0-x22d.google.com with SMTP id i88so39228529pfk.2 for ; Tue, 15 Nov 2016 17:49:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=qEgHIRqnEh+u/sZ9Z828VnlXyygBbqDvCq72QpyIKP8=; b=eCY/Rgwnj0aLBE7FbdIXYlhcE3RMTWNEEIuSRelQwmSVy6Wzb9SsmY5ODCl2w33fy1 /Ill71AE+t5RUORhylcl7nuLSc5gZBp0CcB7oVe3cAzEg9qlJKZhnt/UdigwpALb3kcg fx6veWptzCkvYtW6AHiNuydspH3My+uk3r4i2KKpdzz1X0L4zqOhEvwUKw/IC2gV1QDE u0PiTFwTyKh5harzUiGK/vZb0C9SIVBIqEeELl5V7VXkbw0chU7KE2psI7Hf+KAjy4LF PCAU0p/wbV8FoSmMb6se7BpsLHlPilHMCRy/Mr6CBUzU0oAORIDiFqHs3DLbIlrC5/32 jqGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=qEgHIRqnEh+u/sZ9Z828VnlXyygBbqDvCq72QpyIKP8=; b=Ay/j1DQYNkTqs4yLiGsEW3PStk7dWAZX7EVK8Nmi7i8CtcATM0nMMozezsFa2ISHcA j6WY6CAt8xUkUiCMwIwJSbJWTQdR9GreUJb7DqEsfPBenakAhfCD+ooa0hQaKhXVgxyh 4yPmI+CnmCLbKerLC2NvZa1CkuhT2AMBlkRYAnnIGgea23xuT1We288puhTUAwYT0YO6 rDPTn1rcL7K8y5WikDa5o3bgUlzuMzAPuHUj0b6jS7ST3eAyIHoLf26WUzW0q5yiSTBb OjtNjfHDG6JO6ha/xiRN4Y/ayeYg4aO6INJWqi6VQkYkOKWkV9legfBYIx5o7CA247f3 yZ6g== X-Gm-Message-State: ABUngvdeXkgKESXpG0LV/ixQrigHFayP1MKFceDJgXlesJ/CI9ibn3FgK03F4oR2KMJDhg== X-Received: by 10.99.5.21 with SMTP id 21mr2540452pgf.32.1479260993665; Tue, 15 Nov 2016 17:49:53 -0800 (PST) Received: from t2001067c03700128b0cd002daee86f00.v6.meeting.ietf.org (t2001067c03700128b0cd002daee86f00.v6.meeting.ietf.org. [2001:67c:370:128:b0cd:2d:aee8:6f00]) by smtp.gmail.com with ESMTPSA id c128sm46993356pfc.39.2016.11.15.17.49.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Nov 2016 17:49:53 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: Date: Wed, 16 Nov 2016 10:49:47 +0900 To: "" X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [TLS] Resolving the Ed448 context issue in RFC4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 16 Nov 2016 01:49:55 -0000 Hi, all As mentioned in Tuesday's session, Ed448 and Ed25519ctx add a new = parameter to the signature function: a context string. Setting this = string to a different value for each application (where application = could be "PKIX", "TLS", "IKE") leads to different results and thus a = signature made in one context does not validate in another context. This = reduces the attack surface for attacks involving signing oracles. The CFRG draft suggests that "contexts SHOULD NOT be used = opportunistically, as that kind of use is very error-prone. If contexts = are used, one SHOULD require all signature schemes available for use in = that purpose support contexts". As I don't think this WG is ready to = deprecate RSA, DSA, and ECDSA in one fell swoop, I think we should not = use contexts.=20 So I suggest to add the following sentence at the end of the fifth = paragraph section 5.10 ("All EdDSA computations MUST be performed...") = of the rfc4492bis draft: The context parameter for Ed448 MUST be set to the empty string. Comments? Yoav= From nobody Tue Nov 15 17:59:37 2016 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 415EA129616 for ; Tue, 15 Nov 2016 17:59:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=armh.onmicrosoft.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 fO5P7XcRssAt for ; Tue, 15 Nov 2016 17:59:34 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0074.outbound.protection.outlook.com [104.47.1.74]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB9A012964E for ; Tue, 15 Nov 2016 17:59:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=kyyU8n2qR7TfpXu2ca6QOsMvBN2N+GusnaXEqel6nLM=; b=BJe+FADH2jkkStnfB0XNATt76z9QSyRF68yWHmWpYT7oEPDbGcFzYB/I3BTTKNeckUvve2R/52d5p2xS6C3kQKGRdTtOviGAFWUQaszfPu6j/Sptixg0U7knrsTMJVTYCc+DvJQ0WVhuy19WzsrkRBKeBndp7ngaZMB6dqfrrew= Received: from HE1PR0802MB2475.eurprd08.prod.outlook.com (10.175.34.148) by HE1PR0802MB2475.eurprd08.prod.outlook.com (10.175.34.148) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Wed, 16 Nov 2016 01:59:27 +0000 Received: from HE1PR0802MB2475.eurprd08.prod.outlook.com ([10.175.34.148]) by HE1PR0802MB2475.eurprd08.prod.outlook.com ([10.175.34.148]) with mapi id 15.01.0734.007; Wed, 16 Nov 2016 01:59:27 +0000 From: Hannes Tschofenig To: Eric Rescorla , Stephen Farrell Thread-Topic: [TLS] extending the un-authenticated DTLS header Thread-Index: AQHSPnbTzGwhOuy3n0OG26ZgyhjKBKDZPRuAgAABu4CAAZ2qQA== Date: Wed, 16 Nov 2016 01:59:27 +0000 Message-ID: References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Hannes.Tschofenig@arm.com; x-originating-ip: [31.133.133.129] x-microsoft-exchange-diagnostics: 1; HE1PR0802MB2475; 7:BArDpNrxDWpAFCkm5m8vy/YwrFGVvKcTzFmnYDgxcv0PjEoAnBTGNKQlTmLUaYT2huCvo6shdwWde/wuOT6bZaChPUpfkxLyVnL+nUV19n0MtNhdl9UjGOOIWT4VyByv1MSr1DYDvEfu0LZZNCnDYQhTTCy0VEfNIrx12HMUwr2YXQSVwpCiaKwued26Nf/h0UexZii9//DQs6wnGgTFYKy4/dYAhh0Dy0WYicfXVhx4rnv6zlotJl/2ZDhhc1LxzrNHAgsdakZuP7erHHsiJuvDq6p0JnypX39QhWBr7cMom1KwBSi8yOhUcxTef7L9uGCkl0vLBBYGd5Zuj7gX123l6R3qe1FszDvwnajlm8g= x-ms-office365-filtering-correlation-id: 787c9d24-d6ae-4553-23e3-08d40dc43228 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:HE1PR0802MB2475; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6061324)(6072148); SRVR:HE1PR0802MB2475; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0802MB2475; x-forefront-prvs: 01283822F8 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(40434004)(189002)(86362001)(66066001)(101416001)(106116001)(106356001)(68736007)(105586002)(5001770100001)(6506003)(8676002)(189998001)(122556002)(97736004)(6116002)(7696004)(790700001)(102836003)(3846002)(2950100002)(3660700001)(76176999)(5890100001)(33656002)(81166006)(9686002)(74316002)(8936002)(4326007)(3280700002)(76576001)(7736002)(7846002)(92566002)(5660300001)(229853002)(2900100001)(54356999)(77096005)(50986999)(87936001)(2906002)(81156014); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR0802MB2475; H:HE1PR0802MB2475.eurprd08.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: arm.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_HE1PR0802MB2475780DD8B4516827AF0BF9FABE0HE1PR0802MB2475_" MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Nov 2016 01:59:27.0513 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0802MB2475 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 16 Nov 2016 01:59:35 -0000 --_000_HE1PR0802MB2475780DD8B4516827AF0BF9FABE0HE1PR0802MB2475_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIEknZCBiZSBpbnRlcmVzdGVkIGluIGFuIGFuYWx5c2lzIG9mIHRoZSBwb3RlbnRpYWwgcHJp dmFjeQ0KaW1wYWN0cyBvZiB0aGlzLiBJc24ndCB0aGlzIG1vcmUgb3IgbGVzcyB0aGUgc2FtZSBh cyBkb2luZw0KU1BVRC1mb3ItRFRMUz8gKElmIG5vdCwgc29ycnkgZm9yIGRyYWdnaW5nIGluIGNv bnRyb3ZlcnN5Oi0pDQoNCkkgZG9u4oCZdCBrbm93IFNQVUQgYnV0IEkgc2VlIHRoaXMgd29yayBw cm92aWRpbmcgdGhlIHNhbWUgZnVuY3Rpb25hbGl0eSBhcyB0aGUgU2VjdXJpdHkgUGFyYW1ldGVy IEluZGV4IChTUEkpIGluIHRoZSBJUHNlYyBFU1AgUkZDLg0KU28gZmFyLCBJIGhhdmUgbm90IGhl YXJkIHRlcnJpYmxlIGNvbmNlcm5zIGFib3V0IHRoZSBwcml2YWN5IHByb3BlcnRpZXMgb2YgSVBz ZWMgRVNQLg0KDQpDaWFvDQpIYW5uZXMNCg0KSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRz IG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNj bG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVy cG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55IG1lZGl1bS4gVGhh bmsgeW91Lg0K --_000_HE1PR0802MB2475780DD8B4516827AF0BF9FABE0HE1PR0802MB2475_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJcGFub3NlLTE6NSAwIDAgMCAwIDAgMCAwIDAgMDt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIg MiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFu Iiwic2VyaWYiO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGNtOw0KCW1hcmdpbi1yaWdodDow Y207DQoJbWFyZ2luLWJvdHRvbTowY207DQoJbWFyZ2luLWxlZnQ6MzYuMHB0Ow0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBO ZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5ob2VuemINCgl7bXNvLXN0eWxlLW5hbWU6aG9lbnpi O30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJY29sb3I6IzFGNDk3RDt9DQou TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWls eToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30N CkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIu MHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk U2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDANCgl7bXNvLWxpc3Qt aWQ6NjIzMTIwNjAyOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRl LWlkczoxODk2MDA2MTE0IC05MjE3ODE2NzIgMTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMg MTM0ODA3NTU1IDEzNDgwNzU1NyAxMzQ4MDc1NTMgMTM0ODA3NTU1IDEzNDgwNzU1Nzt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXN0YXJ0LWF0OjA7DQoJbXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+DmDsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4 LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6 Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjsNCgljb2xv cjojMUY0OTdEO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0xOC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpl eHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6 ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0t Pg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LTE4LjBwdDttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+PCFbaWYgIXN1cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdu b3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90 OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SSdkIGJlIGludGVyZXN0 ZWQgaW4gYW4gYW5hbHlzaXMgb2YgdGhlIHBvdGVudGlhbCBwcml2YWN5PGJyPg0KaW1wYWN0cyBv ZiB0aGlzLiBJc24ndCB0aGlzIG1vcmUgb3IgbGVzcyB0aGUgc2FtZSBhcyBkb2luZzxicj4NClNQ VUQtZm9yLURUTFM/IChJZiBub3QsIHNvcnJ5IGZvciBkcmFnZ2luZyBpbiBjb250cm92ZXJzeTot KTxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIGRvbuKAmXQga25vdyBTUFVEIGJ1 dCBJIHNlZSB0aGlzIHdvcmsgcHJvdmlkaW5nIHRoZSBzYW1lIGZ1bmN0aW9uYWxpdHkgYXMgdGhl IFNlY3VyaXR5IFBhcmFtZXRlciBJbmRleCAoU1BJKSBpbiB0aGUgSVBzZWMgRVNQIFJGQy4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5TbyBmYXIsIEkgaGF2ZSBub3QgaGVhcmQgdGVy cmlibGUgY29uY2VybnMgYWJvdXQgdGhlIHByaXZhY3kgcHJvcGVydGllcyBvZiBJUHNlYyBFU1Au DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2Nv bG9yOiMxRjQ5N0QiPkNpYW88YnI+DQpIYW5uZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K SU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9mIHRoaXMgZW1haWwgYW5kIGFueSBhdHRh Y2htZW50cyBhcmUgY29uZmlkZW50aWFsIGFuZCBtYXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5k ZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBkaXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55IG90 aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBhbnkgcHVycG9zZSwNCiBvciBzdG9yZSBvciBjb3B5IHRo ZSBpbmZvcm1hdGlvbiBpbiBhbnkgbWVkaXVtLiBUaGFuayB5b3UuDQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_HE1PR0802MB2475780DD8B4516827AF0BF9FABE0HE1PR0802MB2475_-- From nobody Tue Nov 15 18:03:36 2016 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 5DB64129411 for ; Tue, 15 Nov 2016 18:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.798 X-Spam-Level: X-Spam-Status: No, score=-5.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie 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 XDm4ftyhH-Yo for ; Tue, 15 Nov 2016 18:03:32 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BACBD128874 for ; Tue, 15 Nov 2016 18:03:31 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id EEF5BBE39; Wed, 16 Nov 2016 02:03:28 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_CYf2LghwDs; Wed, 16 Nov 2016 02:03:27 +0000 (GMT) Received: from [10.87.48.210] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 3394ABE38; Wed, 16 Nov 2016 02:03:27 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1479261807; bh=ZOCoFozzBRTKsLo/rudU3kVQfU6ek5OMHXXZ3gf3EM0=; h=Subject:To:References:Cc:From:Date:In-Reply-To:From; b=OqdM6NGchuW92wtgUsTViFVxE7Qr3k5swPYkHVVSWdXPmoUBL/XKtf/NU1NNDnSsn OZ+LmTIWnMhxvm1X1PvzTB0/hlqkRR6W+CeoFzQ51PgEdR4QoLRXY1g1vgo4O6w+kC iGSnbrL20EDvqYCTjvX7j3PI0FGY8bhv8YSrhwXA= To: Hannes Tschofenig , Eric Rescorla References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> From: Stephen Farrell Openpgp: id=D66EA7906F0B897FB2E97D582F3C8736805F8DA2; url= Message-ID: Date: Wed, 16 Nov 2016 02:03:27 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="------------ms090901050506040307070405" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 16 Nov 2016 02:03:34 -0000 This is a cryptographically signed message in MIME format. --------------ms090901050506040307070405 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 16/11/16 01:59, Hannes Tschofenig wrote: > =C3=98 I'd be interested in an analysis of the potential privacy > impacts of this. Isn't this more or less the same as doing > SPUD-for-DTLS? (If not, sorry for dragging in controversy:-) >=20 > I don=E2=80=99t know SPUD but I see this work providing the same functi= onality as the Security Parameter Index (SPI) in the IPsec ESP RFC. > So far, I have not heard terrible concerns about the privacy properties= of IPsec ESP. >=20 Yes, to be fair - having had a quick look at the draft it does not seem to have the problems that SPUD/PLUS could have had. Cheers, S. > Ciao > Hannes >=20 > IMPORTANT NOTICE: The contents of this email and any attachments are co= nfidential and may also be privileged. If you are not the intended recipi= ent, please notify the sender immediately and do not disclose the content= s to any other person, use it for any purpose, or store or copy the infor= mation in any medium. Thank you. >=20 --------------ms090901050506040307070405 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CvIwggUIMIID8KADAgECAhBPzaE7pzYviUJyhmHTFBdnMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwMjA5MDkyODE1WhcNMTcwMjA5MDkyODE1WjBOMSIwIAYDVQQDDBlzdGVw aGVuLmZhcnJlbGxAY3MudGNkLmllMSgwJgYJKoZIhvcNAQkBFhlzdGVwaGVuLmZhcnJlbGxA Y3MudGNkLmllMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAtuC0rYze/2JinSra C9F2RjGdQZjNALLcW9C3WKTwYII3wBslobmHuPEYE5JaGItmzuKnAW619R1rD/kfoNWC19N3 rBZ6UX9Cmb9D9exCwYIwVuSwjrCQWGxgCtNQTrwKzCCpI790GRiMTvxvO7UmzmBrCaBLiZW5 R0fBjK5Yn6hUhAzGBkNbkIEL28cLJqH0yVz7Kl92OlzrQqTPEts5m6cDnNdY/ADfeAX18c1r dxZqcAxhLotrCqgsVA4ilbQDMMXGTLlB5TP35HeWZuGBU7xu003rLcFLdOkD8xvpJoYZy9Kt 3oABXPS5yqtMK+XCNdqmMn+4mOtLwQSMmPCSiQIDAQABo4IBuTCCAbUwCwYDVR0PBAQDAgSw MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBQJ QhvwQ5Fl372Z6xqo6fdn8XejTTAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBv BggrBgEFBQcBAQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5 BggrBgEFBQcwAoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEu Y3J0MDgGA1UdHwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGll bnQxLmNybDAkBgNVHREEHTAbgRlzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllMCMGA1UdEgQc MBqGGGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tLzBGBgNVHSAEPzA9MDsGCysGAQQBgbU3AQIE MCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG 9w0BAQsFAAOCAQEArzrSv2C8PlBBmGuiGrzm2Wma46/KHtXmZYS0bsd43pM66Pc/MsqPE0HD C1GzMFfwB6BfkJn8ijNSIhlgj898WzjvnpM/SO8KStjlB8719ig/xKISrOl5mX55XbFlQtX9 U6MrqRgbDIATxhD9IDr+ryvovDzChqgQj7mt2jYr4mdlRjsjod3H1VY6XglRmaaNGZfsCARM aE/TU5SXIiqauwt5KxNGYAY67QkOBs7O1FkSXpTk7+1MmzJMF4nP8QQ5n8vhVNseF+/Wm7ai 9mtnrkLbaznMsy/ULo/C2yuLUWTbZZbf4EKNmVdme6tUDgYkFjAFOblfA7W1fSPiQGagYzCC BeIwggPKoAMCAQICEGunin0K14jWUQr5WeTntOEwDQYJKoZIhvcNAQELBQAwfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTE1MTIxNjAxMDAwNVoXDTMwMTIxNjAxMDAwNVowdTELMAkGA1UEBhMC SUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmlj YXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQTCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAL192vfDon2D9luC/dtbX64eG3XAtRmv mCSsu1d52DXsCR58zJQbCtB2/A5uFqNxWacpXGGtTCRk9dEDBlmixEd8QiLkUfvHpJX/xKnm VkS6Iye8wUbYzMsDzgnpazlPg19dnSqfhM+Cevdfa89VLnUztRr2cgmCfyO9Otrh7LJDPG+4 D8ZnAqDtVB8MKYJL6QgKyVhhaBc4y3bGWxKyXEtx7QIZZGxPwSkzK3WIN+VKNdkiwTubW5PI dopmykwvIjLPqbJK7yPwFZYekKE015OsW6FV+s4DIM8UlVS8pkIsoGGJtMuWjLL4tq2hYQuu N0jhrxK1ljz50hH23gA9cbMCAwEAAaOCAWQwggFgMA4GA1UdDwEB/wQEAwIBBjAdBgNVHSUE FjAUBggrBgEFBQcDAgYIKwYBBQUHAwQwEgYDVR0TAQH/BAgwBgEB/wIBADAyBgNVHR8EKzAp MCegJaAjhiFodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwZgYIKwYBBQUHAQEE WjBYMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5zdGFydHNzbC5jb20wMAYIKwYBBQUHMAKG JGh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2NlcnRzL2NhLmNydDAdBgNVHQ4EFgQUJIFsOWG+ SQ+PtxtGK8kotSdIbWgwHwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwPwYDVR0g BDgwNjA0BgRVHSAAMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Bv bGljeTANBgkqhkiG9w0BAQsFAAOCAgEAi+P3h+wBi4StDwECW5zhIycjBL008HACblIf26HY 0JdOruKbrWDsXUsiI0j/7Crft9S5oxvPiDtVqspBOB/y5uzSns1lZwh7sG96bYBZpcGzGxpF NjDmQbcM3yl3WFIRS4WhNrsOY14V7y2IrUGsvetsD+bjyOngCIVeC/GmsmtbuLOzJ606tEc9 uRbhjTu/b0x2Fo+/e7UkQvKzNeo7OMhijixaULyINBfCBJb+e29bLafgu6JqjOUJ9eXXj20p 6q/CW+uVrZiSW57+q5an2P2i7hP85jQJcy5j4HzA0rSiF3YPhKGAWUxKPMAVGgcYoXzWydOv Z3UDsTDTagXpRDIKQLZo02wrlxY6iMFqvlzsemVf1odhQJmi7Eh5TbxI40kDGcBOBHhwnaOu mZhLP+SWJQnjpLpSlUOj95uf1zo9oz9e0NgIJoz/tdfrBzez76xtDsK0KfUDHt1/q59BvDI7 RX6gVr0fQoCyMczNzCTcRXYHY0tq2J0oT+bsb6sH2b4WVWAiJKnSYaWDjdA70qHX4mq9MIjO /ZskmSY8wtAk24orAc0vwXgYanqNsBX5Yv4sN4Z9VyrwMdLcusP7HJgRdAGKpkR2I9U4zEsN JQJewM7S4Jalo1DyPrLpL2nTET8ZrSl5Utp1UeGp/2deoprGevfnxWB+vHNQiu85o6MxggPM MIIDyAIBATCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBAhBPzaE7pzYviUJyhmHTFBdnMA0GCWCGSAFlAwQCAQUA oIICEzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNjExMTYw MjAzMjdaMC8GCSqGSIb3DQEJBDEiBCAheDFlZr+Oe7gwr3000p5Vyq6LOsNQOspJtPzwUe/B RjBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcN AwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMC AgEoMIGaBgkrBgEEAYI3EAQxgYwwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzCB nAYLKoZIhvcNAQkQAgsxgYyggYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29t IEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYD VQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQT82hO6c2L4lCcoZh0xQXZzANBgkq hkiG9w0BAQEFAASCAQAuqVZ1kI/DVsQ6zqbLV5YXtVrPu3OFvx5nGkD44uatVr8wSRPfkgLI 57kSudO5DxMJqliHMTmwOT9Rppj00+u9vjiSqU+YM+ZmTfQacToThUY/F7e6slJY5YUrQWg2 7fYg9iYxMgypi2Z6V2nJi8vPArCxCVtTHXir4gtDNcUAD2Q9VypnSCRU7sB0v+pPvO+xroUY ENgufgH5/l11kU/J3opoHXj5AfnC9PcAzoXz9FDgStxVtpsDmUEbcYYQi+xW/qD2cYx9ka2Y 7e7kReFjm0biuanHB5HdcfdlIlKxozrhpg0l4Q450jSfqYDLwE/oE9rf7gHIAcJGYk4k9uXY AAAAAAAA --------------ms090901050506040307070405-- From nobody Tue Nov 15 23:37:25 2016 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 EE3D3129660 for ; Tue, 15 Nov 2016 23:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.419 X-Spam-Level: X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 8bvnTc53rMHB for ; Tue, 15 Nov 2016 23:37:04 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DDE61295A8 for ; Tue, 15 Nov 2016 23:37:03 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2DB73C05AA66; Wed, 16 Nov 2016 07:37:03 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.106]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAG7b0vM024000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 16 Nov 2016 02:37:02 -0500 Message-ID: <1479281820.2529.1.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Martin Thomson Date: Wed, 16 Nov 2016 08:37:00 +0100 In-Reply-To: References: <1479201097.12027.10.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Wed, 16 Nov 2016 07:37:03 +0000 (UTC) Archived-At: Cc: Hannes Tschofenig , "tls@ietf.org" Subject: Re: [TLS] extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 16 Nov 2016 07:37:07 -0000 On Tue, 2016-11-15 at 18:20 +0900, Martin Thomson wrote: > On 15 November 2016 at 18:11, Nikos Mavrogiannopoulos m> wrote: > > > > > > > > I'm not seeing quite enough information here to implement > > > this.  How > > > does a server know which of the many HOTP keys it has are in use? > > > Surely you can't use the same HOTP key with every client. > > > > Not sure I understand the question, but I'd suggest to read the > > text on > > generating the hotp keys. > > > OK, I re-read it.  It wasn't particularly clear from the overview. > But you generate the HOTP based on an exporter.  That means that the > server has no control over the contents of the CID, direct or > otherwise.  This means that you can guarantee privacy, but it forces > the server to do an exhaustive search of all of its active > connections > (that is, O(N)) when it gets a 5-tuple mismatch. > > There are probably designs that don't have this property.  For > instance, the server could propose an identifier or set of > identifiers.  That means that a bad server could willfully break the > privacy property, but it also means that it doesn't have the scaling > issues. I think Thomas reply addresses that, or we must have misunderstood what you mean above. I think however that we are getting outside the scope of the initial discussion. Do you have a proposal which changes the TLSrecord header? If yes would you be interested in discussing ways to combine that, or ways to make the header extendable? regards, Nikos From nobody Wed Nov 16 02:21:18 2016 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 047391296F3 for ; Wed, 16 Nov 2016 02:21:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.901 X-Spam-Level: X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 rmFyNiQk_yz1 for ; Wed, 16 Nov 2016 02:21:14 -0800 (PST) Received: from smtp6-v.fe.bosch.de (smtp6-v.fe.bosch.de [IPv6:2a03:cc00:ff0:100::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DD0129537 for ; Wed, 16 Nov 2016 02:21:13 -0800 (PST) Received: from vsmta14.fe.internet.bosch.com (unknown [10.4.98.54]) by imta24.fe.bosch.de (Postfix) with ESMTP id EDEBCD801DB for ; Wed, 16 Nov 2016 11:21:10 +0100 (CET) Received: from imbvw2exc01.bosch-si.com (vsgw23.fe.internet.bosch.com [10.4.98.23]) by vsmta14.fe.internet.bosch.com (Postfix) with ESMTP id 66C2EA40CAE for ; Wed, 16 Nov 2016 11:21:10 +0100 (CET) Received: from IMBPW2EXD01.bosch-si.com ([fe80::d052:f355:928e:e5ba]) by imbvw2exc01.bosch-si.com ([::1]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 11:21:41 +0100 From: "Kraus Achim (INST/ESY1)" To: "tls@ietf.org" Thread-Topic: [TLS] [ALU] Re: extending the un-authenticated DTLS header Thread-Index: AQHSPw8nFDjstdrZ902zFk9/+RE1u6DbZUXA Date: Wed, 16 Nov 2016 10:21:41 +0000 Message-ID: References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.22.83.125] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-TM-AS-MML: disable X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22700.006 X-TMASE-MatchedRID: qo4kGEUleplLfdwP+8LWGxmiTJb38WRepfVcx39Kq+4wFVxto+mLMHkp Nl+k3Px70i41U+l4JIhPqT/xzbGJfWTFilzGBdRxqJst3mlmdq4YlE/kjooKo7J3rmpkUU+TWU4 PVaxZEWP+cTYjc30iLS83Rst4LUB+mNrlAIQG7r/bNDWQseUeZcmZx4YdgiXB/9WTKGBWZFOoAb qESdJED3si3gD9jR5He4C1EulbDB1CMOF2vSwLTPHkpkyUphL9IcCiCHZJTlep7t/yrVnxkCZ9x AZfX8Ihakml/g8mox3DBBlXSY941TItqiewRFZO8lHxQZgd6ADNbZoHWAcdk1pbYq2f4jz+WbzY 4GA2m4u4f1A2F1rkO7Bdb9rysz6qW9DaXGhRJeDwtZfBooJ6awuK1hIitSIH51ONI4UL++qjxYy RBa/qJSw7AP50bcPJQs9S/5dKsKXdB/CxWTRRuyUIayx+Skid Archived-At: Subject: Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 16 Nov 2016 10:21:17 -0000 Hi, I'm still wondering, why the "clashing" calculations (section 4) are only b= ased on the number of clients and not also on the length of the hash chain. As I understood the hash chain, the DTLS server and client calculates a lis= t of CIDs. Though the client chose one, the server has to prepare for the (= left) list of CIDs. So even assuming that in average half of the list is al= ready used, I think the length of that list has influence on the clashing. Mit freundlichen Gr=FC=DFen / Best regards Achim Kraus Bosch Software Innovations GmbH Communications (INST/ESY1) Stuttgarter Stra=DFe 130 71332 Waiblingen GERMANY www.bosch-si.de www.blog.bosch-si.com=20 Registered office: Berlin, Register court: Amtsgericht Charlottenburg, HRB = 148411 B Executives: Dr.-Ing. Rainer Kallenbach; Michael Hahn -----Urspr=FCngliche Nachricht----- Von: TLS [mailto:tls-bounces@ietf.org] Im Auftrag von Fossati, Thomas (Noki= a - GB) Gesendet: Dienstag, 15. November 2016 08:08 An: Martin Thomson ; Eric Rescorla Cc: Hannes Tschofenig ; tls@ietf.org Betreff: Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header On 15/11/2016 03:51, "TLS on behalf of Martin Thomson" wrote: >On 15 November 2016 at 10:16, Eric Rescorla wrote: >>> I'd be interested in an analysis of the potential privacy impacts of=20 >>> this. Isn't this more or less the same as doing SPUD-for-DTLS? (If=20 >>> not, sorry for dragging in controversy:-) >> >> >> It would no doubt depend what you put there. > >Which is why I'm interested in seeing Nikos' (unpublished?) draft. Published: https://tools.ietf.org/html/draft-mavrogiannopoulos-tls-cid-00 Working copy: https://thomas-fossati.github.io/draft-tls-cid/ Slides for today, "DTLS Optimizations for IoT Deployments": https://www.ietf.org/proceedings/97/slides/slides-97-tls-dtls-optimizations -for-iot-deployments-00.pptx _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Wed Nov 16 05:55:34 2016 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 5D50F1297CF for ; Wed, 16 Nov 2016 05:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 K5GzM02RPuYu for ; Wed, 16 Nov 2016 05:55:31 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (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 BC7C512953D for ; Wed, 16 Nov 2016 05:55:30 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id n21so175656026qka.3 for ; Wed, 16 Nov 2016 05:55:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=ArxL5mL+gicDxl7pZo7FCmkfrGzTMf0dXlkPTncjM1E=; b=moZkS7lWZ4py7M66QjMlJcu8FPi+hJBRS/S70DcyrFvxcw2i528df0yzbspDBrrD+Z Cw62xVjsm9YH/HBPreW+jMaMIV00XNv+jTv3g5aV9wLmyhXB5Ord6u1/vvXFcn+HmFCV 1XqMOx/G3oI/oXj/sjQwF5RyKfTN3yvnjayQD1OVAHMGIjd+cJEbvOTBsH3PYOqusYop FPDnNSWd5Kvg7ouoP2t2JfjPoy323bH1R0IoQmcPAOt3XKP+f1hJ9nJOfg70oAkYqUdE oFzfUTRi0MeHhQ7n0j4h8A0KacjP4olFyPA1PwWQgt23PpMSpqlxZJ2ViJZtSzFN7QGi 2Fsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=ArxL5mL+gicDxl7pZo7FCmkfrGzTMf0dXlkPTncjM1E=; b=KRg5r3Ifu14881FpwtC8RoOz4fuHqLz1bufuSKOcowHFirMnfh/jV9p521oKA4zs/q Xe94TVkmChI/jS2zT2HE9ycJGFsZt7Qs86Ie/ct/XHWxb+5nnvEha4+WPrn6yFt2Edho 3QEnx+rL8bgN9FEXYBtuEB9T9vMb+BbGtWK6qX1ChbdrMvgAU0Mp94RsCTe+ueH1jfPN 0CJuky4rMPJBhWk7www1eqFtGUsg5A8l+mPosGiSqQuLAGkNEdngGqDmP1eImrFdCsr6 yy8ghnmDB2Vy1i4Eb5SYp3lJJbB2FsEE8gVmrMeYPGW+rSBQXMEA6E8MNo7BDr+0tANR K9Hw== X-Gm-Message-State: AKaTC01TQKXkxuSxo1PqXQ1qOHj8T8mUWeIKXTvPor1nOeNG4k7YAk6M3/pekGQ26GJTwA== X-Received: by 10.55.7.17 with SMTP id 17mr3989991qkh.228.1479304529909; Wed, 16 Nov 2016 05:55:29 -0800 (PST) Received: from [192.168.1.151] (c-73-173-147-199.hsd1.md.comcast.net. [73.173.147.199]) by smtp.gmail.com with ESMTPSA id y52sm17787583qty.11.2016.11.16.05.55.28 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 16 Nov 2016 05:55:29 -0800 (PST) Content-Type: multipart/signed; boundary="Apple-Mail=_2FDEBD07-A09A-455B-BCDF-F1D69A21C0DD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Matthew Green In-Reply-To: Date: Wed, 16 Nov 2016 08:55:19 -0500 Message-Id: <2BDF489D-E968-4C47-9E2B-2FEFA0217367@gmail.com> References: To: ynir.ietf@gmail.com X-Mailer: Apple Mail (2.2104) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 16 Nov 2016 13:55:32 -0000 --Apple-Mail=_2FDEBD07-A09A-455B-BCDF-F1D69A21C0DD Content-Type: multipart/alternative; boundary="Apple-Mail=_A5A86B39-7595-4EF7-95C3-E1CDB07EB6AF" --Apple-Mail=_A5A86B39-7595-4EF7-95C3-E1CDB07EB6AF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Thanks for pointing out the line in Appendix D.1. I also agree that the = proposal requires no changes to the current 1.3 specification, which is = very much a point in its favor. I don=E2=80=99t think there is a desired action from the TLS-WG. The = goal is simply to have a document that other implementers can reference = and work from, and preferably one that is developed openly within view = of the working group =E2=80=94 rather than having the implementers do = this in another forum. A side benefit is that this Draft also help to = drive some thinking on the part of the TLS protocol designers around how = TLS 1.3 will actually be deployed in certain environments (see e.g., = related thread on point validation). Matt > On Nov 14, 2016, at 10:50 PM, tls-request@ietf.org wrote: >=20 > Message: 4 > Date: Tue, 15 Nov 2016 10:28:05 +0900 > From: Yoav Nir > > To: Sean Turner > > Cc: ">" > > Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D > Action: draft-green-tls-static-dh-in-tls13-00.txt) > Message-ID: <2F41D793-19E2-4C04-A914-E2F2581F844E@gmail.com = > > Content-Type: text/plain; charset=3Dus-ascii >=20 > If I understand this draft correctly, this draft describes server = behavior. It does not change anything within the TLS 1.3 protocol. IOW a = server doing this will interoperate with any client. >=20 > I searched the tls13 draft to see if it has anything to say about = this, and the only thing I found was this line in appendix D.1: >=20 > If fresh (EC)DHE keys are used for each connection, then the output = keys are forward secret. >=20 > So a server is not required to generate fresh (EC)DHE keys for each = connection. In fact, generating fresh keys periodically and discarding = the old ones are a legitimate way to achieve forward secrecy. What this = draft does differently is to save the old (EC)DHE private keys, which = loses the forward secrecy. >=20 > So given that what the draft proposes is possible with the current TLS = 1.3, what do the proponents want? Is it just to have a document that = describes this server behavior? >=20 > Yoav --Apple-Mail=_A5A86B39-7595-4EF7-95C3-E1CDB07EB6AF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Thanks for pointing out the line in Appendix D.1. I also = agree that the proposal requires no changes to the current 1.3 = specification, which is very much a point in its favor.
I don=E2=80=99t think there is a = desired action from the TLS-WG. The goal is simply to have a document = that other implementers can reference and work from, and preferably one = that is developed openly within view of the working group =E2=80=94 = rather than having the implementers do this in another forum. A side = benefit is that this Draft also help to drive some thinking on the part = of the TLS protocol designers around how TLS 1.3 will actually be = deployed in certain environments (see e.g., related thread on point = validation).

Matt

On = Nov 14, 2016, at 10:50 PM, tls-request@ietf.org wrote:

Message: 4
Date: Tue, 15 Nov 2016 10:28:05 +0900
From: Yoav Nir <ynir.ietf@gmail.com>
To: Sean Turner = <sean@sn3rd.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] TLS Visibility Inside the = Data Center (was: I-D
Action: = draft-green-tls-static-dh-in-tls13-00.txt)
Message-ID: <2F41D793-19E2-4C04-A914-E2F2581F844E@gmail.com>
Content-Type: text/plain; = charset=3Dus-ascii

If I understand this draft = correctly, this draft describes server behavior. It does not change = anything within the TLS 1.3 protocol. IOW a server doing this will = interoperate with any client.

I searched the tls13 draft = to see if it has anything to say about this, and the only thing I found = was this line in appendix D.1:

  If fresh (EC)DHE keys are used for = each connection, then the output keys are forward secret.

So a server is not required to generate fresh = (EC)DHE keys for each connection. In fact, generating fresh keys = periodically and discarding the old ones are a legitimate way to achieve = forward secrecy. What this draft does differently is to save the old = (EC)DHE private keys, which loses the forward secrecy. 

So given that what the draft proposes is = possible with the current TLS 1.3, what do the proponents want? Is it = just to have a document that describes this server behavior?

Yoav

= --Apple-Mail=_A5A86B39-7595-4EF7-95C3-E1CDB07EB6AF-- --Apple-Mail=_2FDEBD07-A09A-455B-BCDF-F1D69A21C0DD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJYLGVPAAoJEDgwLl99RanZCeYIALIk6SmN47ffjuncSKJiPtVx pXcIqekyTHSaRp5xYe20ipOE9KHPiBa297pI0bUwU0i9U9OkAH/VC68Zuvfip5ya j6rBg6RfwS8bSZ7gMGeqYyA55ld8WJpnWorAy/8QMv5ek3Aq/laTWnzzR8YOtq+m Wfo0V+swrmZNJQwrRWYBKKanhSTMew5zIgoir1vZO8oED2zj/k70DmEnDeVAebON l9m2FXVi7S4SJJ0OVU+kewtxv40p5xbcu5jsV+JMtel6Rfd1n5UIRhNaH7Ojib8J tP0zBXJ8TdFxxQ0NtqnmlEUMryDhe3lP6OLvx/Ncj6Ye/hK8ybLck9lXrya2ngo= =HwV1 -----END PGP SIGNATURE----- --Apple-Mail=_2FDEBD07-A09A-455B-BCDF-F1D69A21C0DD-- From nobody Wed Nov 16 07:33:43 2016 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 2961D1294B7 for ; Wed, 16 Nov 2016 07:33:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.117 X-Spam-Level: X-Spam-Status: No, score=-4.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 I_irYFAxvZpw for ; Wed, 16 Nov 2016 07:33:40 -0800 (PST) Received: from smtp-p01.blackberry.com (smtp-p01.blackberry.com [208.65.78.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 886A9129652 for ; Wed, 16 Nov 2016 07:33:39 -0800 (PST) Received: from xct107cnc.rim.net ([10.65.161.207]) by mhs211cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 16 Nov 2016 10:33:39 -0500 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT107CNC.rim.net ([fe80::b815:71ef:9f8f:e07c%16]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 10:33:38 -0500 From: Dan Brown To: Matthew Green , "ynir.ietf@gmail.com" Thread-Topic: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt) Thread-Index: AQHSQBEQSiqxIb/8rEKeKScrOWkvZaDbvB3Q Date: Wed, 16 Nov 2016 15:33:37 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF50107C88C@XMB116CNC.rim.net> References: <2BDF489D-E968-4C47-9E2B-2FEFA0217367@gmail.com> In-Reply-To: <2BDF489D-E968-4C47-9E2B-2FEFA0217367@gmail.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.248] Content-Type: multipart/alternative; boundary="_000_810C31990B57ED40B2062BA10D43FBF50107C88CXMB116CNCrimnet_" MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 16 Nov 2016 15:33:42 -0000 --_000_810C31990B57ED40B2062BA10D43FBF50107C88CXMB116CNCrimnet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXNu4oCZdCBwb3NzaWJsZSB0byBhY2hpZXZlIHRoZSBnb2FscyBvZiB0aGlzIHByb3Bvc2FsIHdp dGhvdXQgcmUtdXNpbmcgREggc2VjcmV0cz8NCg0KRm9yIGV4YW1wbGUsIGxldCBESF9zZWNyZXQg PSBLREYgKCBtb25pdG9yaW5nX2tleSwgc2VydmVyLmhlbGxvICwgY2xpZW50LmhlbGxvKSwgb3Ig c29tZXRoaW5nIHNpbWlsYXIuICBJZGVhbGx5LCB0aGUgbW9uaXRvcmluZ19rZXkgc2hvdWxkIGJl IHVwZGF0ZWQgZnJlcXVlbnRseSBhcyBwb3NzaWJsZSAod2hpbGUga2VlcGluZyBpdCBzeW5jaHJv bml6ZWQpLg0KDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIE1hdHRoZXcgR3JlZW4NClNlbnQ6IFdlZG5lc2RheSwgTm92ZW1iZXIgMTYsIDIwMTYg ODo1NSBBTQ0KVG86IHluaXIuaWV0ZkBnbWFpbC5jb20NCkNjOiB0bHNAaWV0Zi5vcmcNClN1Ympl Y3Q6IFJlOiBbVExTXSBUTFMgVmlzaWJpbGl0eSBJbnNpZGUgdGhlIERhdGEgQ2VudGVyICh3YXM6 IEktRCBBY3Rpb246IGRyYWZ0LWdyZWVuLXRscy1zdGF0aWMtZGgtaW4tdGxzMTMtMDAudHh0KQ0K DQpUaGFua3MgZm9yIHBvaW50aW5nIG91dCB0aGUgbGluZSBpbiBBcHBlbmRpeCBELjEuIEkgYWxz byBhZ3JlZSB0aGF0IHRoZSBwcm9wb3NhbCByZXF1aXJlcyBubyBjaGFuZ2VzIHRvIHRoZSBjdXJy ZW50IDEuMyBzcGVjaWZpY2F0aW9uLCB3aGljaCBpcyB2ZXJ5IG11Y2ggYSBwb2ludCBpbiBpdHMg ZmF2b3IuDQoNCkkgZG9u4oCZdCB0aGluayB0aGVyZSBpcyBhIGRlc2lyZWQgYWN0aW9uIGZyb20g dGhlIFRMUy1XRy4gVGhlIGdvYWwgaXMgc2ltcGx5IHRvIGhhdmUgYSBkb2N1bWVudCB0aGF0IG90 aGVyIGltcGxlbWVudGVycyBjYW4gcmVmZXJlbmNlIGFuZCB3b3JrIGZyb20sIGFuZCBwcmVmZXJh Ymx5IG9uZSB0aGF0IGlzIGRldmVsb3BlZCBvcGVubHkgd2l0aGluIHZpZXcgb2YgdGhlIHdvcmtp bmcgZ3JvdXAg4oCUIHJhdGhlciB0aGFuIGhhdmluZyB0aGUgaW1wbGVtZW50ZXJzIGRvIHRoaXMg aW4gYW5vdGhlciBmb3J1bS4gQSBzaWRlIGJlbmVmaXQgaXMgdGhhdCB0aGlzIERyYWZ0IGFsc28g aGVscCB0byBkcml2ZSBzb21lIHRoaW5raW5nIG9uIHRoZSBwYXJ0IG9mIHRoZSBUTFMgcHJvdG9j b2wgZGVzaWduZXJzIGFyb3VuZCBob3cgVExTIDEuMyB3aWxsIGFjdHVhbGx5IGJlIGRlcGxveWVk IGluIGNlcnRhaW4gZW52aXJvbm1lbnRzIChzZWUgZS5nLiwgcmVsYXRlZCB0aHJlYWQgb24gcG9p bnQgdmFsaWRhdGlvbikuDQoNCk1hdHQNCg0KT24gTm92IDE0LCAyMDE2LCBhdCAxMDo1MCBQTSwg dGxzLXJlcXVlc3RAaWV0Zi5vcmc8bWFpbHRvOnRscy1yZXF1ZXN0QGlldGYub3JnPiB3cm90ZToN Cg0KTWVzc2FnZTogNA0KRGF0ZTogVHVlLCAxNSBOb3YgMjAxNiAxMDoyODowNSArMDkwMA0KRnJv bTogWW9hdiBOaXIgPHluaXIuaWV0ZkBnbWFpbC5jb208bWFpbHRvOnluaXIuaWV0ZkBnbWFpbC5j b20+Pg0KVG86IFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbTxtYWlsdG86c2VhbkBzbjNyZC5j b20+Pg0KQ2M6ICI8dGxzQGlldGYub3JnPG1haWx0bzp0bHNAaWV0Zi5vcmc+PiIgPHRsc0BpZXRm Lm9yZzxtYWlsdG86dGxzQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbVExTXSBUTFMgVmlzaWJp bGl0eSBJbnNpZGUgdGhlIERhdGEgQ2VudGVyICh3YXM6IEktRA0KICAgICAgICAgICAgICAgIEFj dGlvbjogZHJhZnQtZ3JlZW4tdGxzLXN0YXRpYy1kaC1pbi10bHMxMy0wMC50eHQpDQpNZXNzYWdl LUlEOiA8MkY0MUQ3OTMtMTlFMi00QzA0LUE5MTQtRTJGMjU4MUY4NDRFQGdtYWlsLmNvbTxtYWls dG86MkY0MUQ3OTMtMTlFMi00QzA0LUE5MTQtRTJGMjU4MUY4NDRFQGdtYWlsLmNvbT4+DQpDb250 ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9dXMtYXNjaWkNCg0KSWYgSSB1bmRlcnN0YW5k IHRoaXMgZHJhZnQgY29ycmVjdGx5LCB0aGlzIGRyYWZ0IGRlc2NyaWJlcyBzZXJ2ZXIgYmVoYXZp b3IuIEl0IGRvZXMgbm90IGNoYW5nZSBhbnl0aGluZyB3aXRoaW4gdGhlIFRMUyAxLjMgcHJvdG9j b2wuIElPVyBhIHNlcnZlciBkb2luZyB0aGlzIHdpbGwgaW50ZXJvcGVyYXRlIHdpdGggYW55IGNs aWVudC4NCg0KSSBzZWFyY2hlZCB0aGUgdGxzMTMgZHJhZnQgdG8gc2VlIGlmIGl0IGhhcyBhbnl0 aGluZyB0byBzYXkgYWJvdXQgdGhpcywgYW5kIHRoZSBvbmx5IHRoaW5nIEkgZm91bmQgd2FzIHRo aXMgbGluZSBpbiBhcHBlbmRpeCBELjE6DQoNCiAgSWYgZnJlc2ggKEVDKURIRSBrZXlzIGFyZSB1 c2VkIGZvciBlYWNoIGNvbm5lY3Rpb24sIHRoZW4gdGhlIG91dHB1dCBrZXlzIGFyZSBmb3J3YXJk IHNlY3JldC4NCg0KU28gYSBzZXJ2ZXIgaXMgbm90IHJlcXVpcmVkIHRvIGdlbmVyYXRlIGZyZXNo IChFQylESEUga2V5cyBmb3IgZWFjaCBjb25uZWN0aW9uLiBJbiBmYWN0LCBnZW5lcmF0aW5nIGZy ZXNoIGtleXMgcGVyaW9kaWNhbGx5IGFuZCBkaXNjYXJkaW5nIHRoZSBvbGQgb25lcyBhcmUgYSBs ZWdpdGltYXRlIHdheSB0byBhY2hpZXZlIGZvcndhcmQgc2VjcmVjeS4gV2hhdCB0aGlzIGRyYWZ0 IGRvZXMgZGlmZmVyZW50bHkgaXMgdG8gc2F2ZSB0aGUgb2xkIChFQylESEUgcHJpdmF0ZSBrZXlz LCB3aGljaCBsb3NlcyB0aGUgZm9yd2FyZCBzZWNyZWN5Lg0KDQpTbyBnaXZlbiB0aGF0IHdoYXQg dGhlIGRyYWZ0IHByb3Bvc2VzIGlzIHBvc3NpYmxlIHdpdGggdGhlIGN1cnJlbnQgVExTIDEuMywg d2hhdCBkbyB0aGUgcHJvcG9uZW50cyB3YW50PyBJcyBpdCBqdXN0IHRvIGhhdmUgYSBkb2N1bWVu dCB0aGF0IGRlc2NyaWJlcyB0aGlzIHNlcnZlciBiZWhhdmlvcj8NCg0KWW9hdg0KDQo= --_000_810C31990B57ED40B2062BA10D43FBF50107C88CXMB116CNCrimnet_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uYXBwbGUtdGFiLXNwYW4NCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtdGFiLXNwYW47fQ0Kc3Bh bi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVk LXNwYWNlO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl cGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3Rl eHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9u dC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47 DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7 cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4N CjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48 IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0 PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5 b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9 ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+SXNu4oCZdCBwb3NzaWJsZSB0byBhY2hp ZXZlIHRoZSBnb2FscyBvZiB0aGlzIHByb3Bvc2FsIHdpdGhvdXQgcmUtdXNpbmcgREggc2VjcmV0 cz88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Rm9yIGV4YW1wbGUsIGxldCBESF9zZWNyZXQgPSBLREYgKCBtb25p dG9yaW5nX2tleSwgc2VydmVyLmhlbGxvICwgY2xpZW50LmhlbGxvKSwgb3Igc29tZXRoaW5nIHNp bWlsYXIuJm5ic3A7IElkZWFsbHksIHRoZSBtb25pdG9yaW5nX2tleSBzaG91bGQgYmUgdXBkYXRl ZCBmcmVxdWVudGx5IGFzIHBvc3NpYmxlDQogKHdoaWxlIGtlZXBpbmcgaXQgc3luY2hyb25pemVk KS4mbmJzcDsgPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gVExTIFttYWlsdG86dGxzLWJv dW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPk1hdHRoZXcgR3JlZW48YnI+DQo8 Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBOb3ZlbWJlciAxNiwgMjAxNiA4OjU1IEFNPGJyPg0KPGI+ VG86PC9iPiB5bmlyLmlldGZAZ21haWwuY29tPGJyPg0KPGI+Q2M6PC9iPiB0bHNAaWV0Zi5vcmc8 YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNdIFRMUyBWaXNpYmlsaXR5IEluc2lkZSB0aGUg RGF0YSBDZW50ZXIgKHdhczogSS1EIEFjdGlvbjogZHJhZnQtZ3JlZW4tdGxzLXN0YXRpYy1kaC1p bi10bHMxMy0wMC50eHQpPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhbmtzIGZvciBwb2ludGluZyBvdXQgdGhlIGxpbmUgaW4gQXBwZW5kaXggRC4xLiBJ IGFsc28gYWdyZWUgdGhhdCB0aGUgcHJvcG9zYWwgcmVxdWlyZXMgbm8gY2hhbmdlcyB0byB0aGUg Y3VycmVudCAxLjMgc3BlY2lmaWNhdGlvbiwgd2hpY2ggaXMgdmVyeSBtdWNoIGEgcG9pbnQgaW4g aXRzIGZhdm9yLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SSBkb27igJl0IHRoaW5rIHRoZXJlIGlzIGEgZGVzaXJlZCBhY3Rpb24gZnJvbSB0aGUgVExTLVdH LiBUaGUgZ29hbCBpcyBzaW1wbHkgdG8gaGF2ZSBhIGRvY3VtZW50IHRoYXQgb3RoZXIgaW1wbGVt ZW50ZXJzIGNhbiByZWZlcmVuY2UgYW5kIHdvcmsgZnJvbSwgYW5kIHByZWZlcmFibHkgb25lIHRo YXQgaXMgZGV2ZWxvcGVkIG9wZW5seSB3aXRoaW4gdmlldyBvZiB0aGUgd29ya2luZyBncm91cCDi gJQgcmF0aGVyIHRoYW4NCiBoYXZpbmcgdGhlIGltcGxlbWVudGVycyBkbyB0aGlzIGluIGFub3Ro ZXIgZm9ydW0uIEEgc2lkZSBiZW5lZml0IGlzIHRoYXQgdGhpcyBEcmFmdCBhbHNvIGhlbHAgdG8g ZHJpdmUgc29tZSB0aGlua2luZyBvbiB0aGUgcGFydCBvZiB0aGUgVExTIHByb3RvY29sIGRlc2ln bmVycyBhcm91bmQgaG93IFRMUyAxLjMgd2lsbCBhY3R1YWxseSBiZSBkZXBsb3llZCBpbiBjZXJ0 YWluIGVudmlyb25tZW50cyAoc2VlIGUuZy4sIHJlbGF0ZWQgdGhyZWFkIG9uDQogcG9pbnQgdmFs aWRhdGlvbikuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk1hdHQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8YmxvY2txdW90ZSBz dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5PbiBOb3YgMTQsIDIwMTYsIGF0IDEwOjUwIFBNLCA8YSBocmVmPSJt YWlsdG86dGxzLXJlcXVlc3RAaWV0Zi5vcmciPg0KdGxzLXJlcXVlc3RAaWV0Zi5vcmc8L2E+IHdy b3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5NZXNzYWdlOiA0PGJyPg0KRGF0ZTogVHVlLCAxNSBOb3YgMjAxNiAxMDoyODowNSAmIzQz OzA5MDA8YnI+DQpGcm9tOiBZb2F2IE5pciAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp5bmly LmlldGZAZ21haWwuY29tIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj55bmlyLmlldGZAZ21haWwuY29tPC9z cGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PGJyPg0KVG86IFNlYW4gVHVybmVyICZsdDs8 L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnNlYW5Ac24zcmQuY29tIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjkuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5z ZWFuQHNuM3JkLmNvbTwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250 LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NCkNjOiAm cXVvdDsmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPnRsc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZxdW90 OyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzp0bHNAaWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJm b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPnRsc0BpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm b250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozxicj4NClN1 YmplY3Q6IFJlOiBbVExTXSBUTFMgVmlzaWJpbGl0eSBJbnNpZGUgdGhlIERhdGEgQ2VudGVyICh3 YXM6IEktRDxicj4NCjxzcGFuIGNsYXNzPSJhcHBsZS10YWItc3BhbiI+Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IDwvc3Bhbj5BY3Rpb246IGRyYWZ0LWdyZWVuLXRscy1zdGF0aWMt ZGgtaW4tdGxzMTMtMDAudHh0KTxicj4NCk1lc3NhZ2UtSUQ6ICZsdDs8L3NwYW4+PGEgaHJlZj0i bWFpbHRvOjJGNDFENzkzLTE5RTItNEMwNC1BOTE0LUUyRjI1ODFGODQ0RUBnbWFpbC5jb20iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjJGNDFENzkzLTE5RTItNEMwNC1BOTE0LUUyRjI1ODFGODQ0RUBnbWFp bC5jb208L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8YnI+DQpDb250ZW50LVR5cGU6 IHRleHQvcGxhaW47IGNoYXJzZXQ9dXMtYXNjaWk8YnI+DQo8YnI+DQpJZiBJIHVuZGVyc3RhbmQg dGhpcyBkcmFmdCBjb3JyZWN0bHksIHRoaXMgZHJhZnQgZGVzY3JpYmVzIHNlcnZlciBiZWhhdmlv ci4gSXQgZG9lcyBub3QgY2hhbmdlIGFueXRoaW5nIHdpdGhpbiB0aGUgVExTIDEuMyBwcm90b2Nv bC4gSU9XIGEgc2VydmVyIGRvaW5nIHRoaXMgd2lsbCBpbnRlcm9wZXJhdGUgd2l0aCBhbnkgY2xp ZW50Ljxicj4NCjxicj4NCkkgc2VhcmNoZWQgdGhlIHRsczEzIGRyYWZ0IHRvIHNlZSBpZiBpdCBo YXMgYW55dGhpbmcgdG8gc2F5IGFib3V0IHRoaXMsIGFuZCB0aGUgb25seSB0aGluZyBJIGZvdW5k IHdhcyB0aGlzIGxpbmUgaW4gYXBwZW5kaXggRC4xOjxicj4NCjxicj4NCiZuYnNwOyZuYnNwO0lm IGZyZXNoIChFQylESEUga2V5cyBhcmUgdXNlZCBmb3IgZWFjaCBjb25uZWN0aW9uLCB0aGVuIHRo ZSBvdXRwdXQga2V5cyBhcmUgZm9yd2FyZCBzZWNyZXQuPGJyPg0KPGJyPg0KU28gYSBzZXJ2ZXIg aXMgbm90IHJlcXVpcmVkIHRvIGdlbmVyYXRlIGZyZXNoIChFQylESEUga2V5cyBmb3IgZWFjaCBj b25uZWN0aW9uLiBJbiBmYWN0LCBnZW5lcmF0aW5nIGZyZXNoIGtleXMgcGVyaW9kaWNhbGx5IGFu ZCBkaXNjYXJkaW5nIHRoZSBvbGQgb25lcyBhcmUgYSBsZWdpdGltYXRlIHdheSB0byBhY2hpZXZl IGZvcndhcmQgc2VjcmVjeS4gV2hhdCB0aGlzIGRyYWZ0IGRvZXMgZGlmZmVyZW50bHkgaXMgdG8g c2F2ZSB0aGUgb2xkIChFQylESEUNCiBwcml2YXRlIGtleXMsIHdoaWNoIGxvc2VzIHRoZSBmb3J3 YXJkIHNlY3JlY3kuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjxicj4NCjxicj4NClNvIGdpdmVuIHRoYXQgd2hhdCB0aGUgZHJhZnQgcHJvcG9zZXMgaXMg cG9zc2libGUgd2l0aCB0aGUgY3VycmVudCBUTFMgMS4zLCB3aGF0IGRvIHRoZSBwcm9wb25lbnRz IHdhbnQ/IElzIGl0IGp1c3QgdG8gaGF2ZSBhIGRvY3VtZW50IHRoYXQgZGVzY3JpYmVzIHRoaXMg c2VydmVyIGJlaGF2aW9yPzxicj4NCjxicj4NCllvYXY8L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+ DQo= --_000_810C31990B57ED40B2062BA10D43FBF50107C88CXMB116CNCrimnet_-- From nobody Wed Nov 16 13:42:02 2016 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 2689A129456 for ; Wed, 16 Nov 2016 13:42:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 tixNqLhEG0cv for ; Wed, 16 Nov 2016 13:41:59 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 55F011293FB for ; Wed, 16 Nov 2016 13:41:59 -0800 (PST) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AD0F0200037; Wed, 16 Nov 2016 21:41:58 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 965F8200033; Wed, 16 Nov 2016 21:41:58 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479332518; bh=U9vJERo/OlJM4V8u1CDWubfu+By6uqXkYhOoeMXMI5c=; l=1418; h=From:To:CC:Date:References:In-Reply-To:From; b=yS5ZSx5PUxfDW513s6lORP15k/EXJeCqnT3c7ubSPpThehhrQ8TKtjwD1tYheoqi5 +2LtvQkp48Yh3TapYCett3O+YWaGrRng91vgrr6ZE/VM/IJjvBPUp/3LhRBc/RE9Iq ywkDLOAN4vV9Hw/zZBOmLuncipl7M+w9LwSnfuH0= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 7C6B898085; Wed, 16 Nov 2016 21:41:58 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 16 Nov 2016 16:41:57 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 16 Nov 2016 16:41:58 -0500 From: "Salz, Rich" To: Dan Brown , Matthew Green , "ynir.ietf@gmail.com" Thread-Topic: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt) Thread-Index: AQHSQBEQdaSzx8vOnUuEzu3p4alLY6DcEUiAgAAQzdA= Date: Wed, 16 Nov 2016 21:41:57 +0000 Message-ID: <6e4cc2bec0c84f0699ac52ffe16bff6d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2BDF489D-E968-4C47-9E2B-2FEFA0217367@gmail.com> <810C31990B57ED40B2062BA10D43FBF50107C88C@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF50107C88C@XMB116CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.116.27] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 16 Nov 2016 21:42:01 -0000 PiBJc27igJl0IHBvc3NpYmxlIHRvIGFjaGlldmUgdGhlIGdvYWxzIG9mIHRoaXMgcHJvcG9zYWwg d2l0aG91dCByZS11c2luZyBESCBzZWNyZXRzPw0KDQo+IEZvciBleGFtcGxlLCBsZXQgREhfc2Vj cmV0ID0gS0RGICggbW9uaXRvcmluZ19rZXksIHNlcnZlci5oZWxsbyAsIGNsaWVudC5oZWxsbyks IG9yIHNvbWV0aGluZyBzaW1pbGFyLiAgSWRlYWxseSwgdGhlIG1vbml0b3Jpbmdfa2V5IHNob3Vs ZCBiZSB1cGRhdGVkIGZyZXF1ZW50bHkgYXMgcG9zc2libGUgKHdoaWxlIGtlZXBpbmcgaXQgc3lu Y2hyb25pemVkKS4gIA0KDQpBcyBhbiBpbXBsZW1lbnRvciAoSSdtIGEgbWVtYmVyIG9mIHRoZSBP cGVuU1NMIGRldiB0ZWFtKSwgSSBzdHJvbmdseSBwcmVmZXIgc29tZXRoaW5nIHRoYXQgaXMgaG9u ZXN0IGFib3V0IHdoYXQgaXQgZG9lcywgcmF0aGVyIHRoYW4gc29tZXRoaW5nIHRoYXQgYXBwZWFy cyB0byBiZSBtb3JlIHRoYW4gdGhhdC4gIFNvIHdoaWxlIHdlIG1pZ2h0IHRha2Ugb24gYSBQUiB0 aGF0IGFsbG93cyB5b3UgdG8gc2V0IGEgc3RhdGljIGtleSBmb3IgdGhlIGhhbmRzaGFrZSwgSSB3 b3VsZCB0cnkgdmVyeSBoYXJkIHRvIHZldG8gc29tZXRoaW5nIGxpa2UgdGhlIGFib3ZlLiAgQW5k IGFzIGEgdXNlciwgSSB3b3VsZCBwcmVmZXIgdG8ga25vdyB3aGF0IGlzIGdvaW5nIG9uOyBJIGNh biBjYWNoZSB0aGUgc2VjcmV0cyBhbmQgaWYgSSBzZWUgdGhlIHNhbWUgb25lIG1vcmUgdGhhbiBv bmNlLCBJIGNhbiB0YWtlIHRoZSBhcHByb3ByaWF0ZSBhY3Rpb24uDQoNCkFuZCB3aGlsZSBJJ20g aGVyZSwgSSBoYXZlIGEgcXVlc3Rpb24gb24gdGhlIGRyYWZ0LiAgRG9lcyB0aGUgY29uc3RydWN0 ICIoRUMpIERIIiBtZWFuICJlcGhlbWVyYWwgREggb3IgRUNESCIsIGxpa2UgYSBzaG9ydGhhbmQ/ DQogDQotLSAgDQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVzDQpNZW1iZXIs IE9wZW5TU0wgRGV2IFRlYW0NCklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRlcjogUmljaFNh bHoNCg0KDQo= From nobody Wed Nov 16 23:10:54 2016 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 A4621129DFC for ; Tue, 8 Nov 2016 13:56:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 4QV_JgYlGxHR for ; Tue, 8 Nov 2016 13:56:34 -0800 (PST) Received: from cavuit01.kulnet.kuleuven.be (rhcavuit01.kulnet.kuleuven.be [IPv6:2a02:2c40:0:c0::25:129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB79D129DFB for ; Tue, 8 Nov 2016 13:56:33 -0800 (PST) X-KULeuven-Envelope-From: roel.peeters@esat.kuleuven.be X-KULeuven-Scanned: Found to be clean X-KULeuven-ID: 3406D1380B6.A7E4A X-KULeuven-Information: Katholieke Universiteit Leuven Received: from icts-p-smtps-2.cc.kuleuven.be (icts-p-smtps-2e.kulnet.kuleuven.be [134.58.240.34]) by cavuit01.kulnet.kuleuven.be (Postfix) with ESMTP id 3406D1380B6 for ; Tue, 8 Nov 2016 22:56:29 +0100 (CET) Received: from [192.168.0.177] (d54C3A026.access.telenet.be [84.195.160.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by icts-p-smtps-2.cc.kuleuven.be (Postfix) with ESMTPSA id 218AA2003B; Tue, 8 Nov 2016 22:56:29 +0100 (CET) X-Kuleuven: This mail passed the K.U.Leuven mailcluster From: Roel Peeters Message-Id: <8C67E8BB-B230-4C84-A890-C57614FF8A46@esat.kuleuven.be> Content-Type: multipart/alternative; boundary="Apple-Mail=_21C184F2-3379-4594-9607-4F932968041D" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Tue, 8 Nov 2016 22:56:28 +0100 In-Reply-To: <201611081626.03635.davemgarrett@gmail.com> To: Dave Garrett References: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> <201611081626.03635.davemgarrett@gmail.com> X-Mailer: Apple Mail (2.3251) Archived-At: X-Mailman-Approved-At: Wed, 16 Nov 2016 23:10:52 -0800 Cc: Jens Hermans , tls@ietf.org Subject: Re: [TLS] COSIC's look on TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 08 Nov 2016 21:56:35 -0000 --Apple-Mail=_21C184F2-3379-4594-9607-4F932968041D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Dave, We are wondering because of this piece of text from the RFC EDITOR just = above paragraph 4.1.4 on Hello Retry Request: RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of = draft versions (see Section 4.2.1.1) of this specification SHOULD NOT = implement this mechanism on either client and server. A pre-RFC client = connecting to RFC servers, or vice versa, will appear to downgrade to = TLS 1.2. With the mechanism enabled, this will cause an interoperability = failure. Best, Roel > On 8 Nov 2016, at 22:26, Dave Garrett wrote: >=20 > On Tuesday, November 08, 2016 09:55:36 am Roel Peeters wrote: >> we are also wondering whether or not the Hello Retry Request will be >> included or omitted in the standard. Leaving it out will make TLS 1.3 >> vulnerable again to downgrade attacks ... >=20 > Why are you wondering about this? HRR is in the specification and = there has been no discussion to remove it. >=20 >=20 > Dave --Apple-Mail=_21C184F2-3379-4594-9607-4F932968041D Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=us-ascii

Hi Dave,

We are wondering because of this piece of text from the RFC EDITOR just above paragraph 4.1.4 on Hello Retry Request:

RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of draft versions (see Section 4.2.1.1) of this specification SHOULD NOT implement this mechanism on either client and server. A pre-RFC client connecting to RFC servers, or vice versa, will appear to downgrade to TLS 1.2. With the mechanism enabled, this will cause an interoperability failure.

Best,
Roel

On 8 Nov 2016, at 22:26, Dave Garrett <davemgarrett@gmail.com> wrote:

On Tuesday, November 08, 2016 09:55:36 am Roel Peeters wrote:
we are also wondering whether or not the Hello Retry Request will be
included or omitted in the standard. Leaving it out will make TLS 1.3
vulnerable again to downgrade attacks ...

Why are you wondering about this? HRR is in the specification and there has been no discussion to remove it.


Dave

--Apple-Mail=_21C184F2-3379-4594-9607-4F932968041D-- From nobody Wed Nov 16 23:15:25 2016 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 8B9F6129556 for ; Wed, 16 Nov 2016 23:15:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 jAgPBwJAYS7d for ; Wed, 16 Nov 2016 23:15:20 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 6950D1294AE for ; Wed, 16 Nov 2016 23:15:20 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id t125so147593791ywc.1 for ; Wed, 16 Nov 2016 23:15:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ys/bRxQQAHjsYcQ1GVvDgSvxj5MRxdS6PdDowbRghFM=; b=EFjHfHx5GK/bqdreO5GVwvL0SnEjPXRQA6uC02hPzLKgXtwLw4nJmNhrXLoJkJPQ9u nfKRB/PmdpxX0x7tuPJ0NoD8s0yE38BrepKfMxITCvgXrNJcu79NC612hA/M+AFqup+k 7yOk3shlRjvgidGfowSopIXYtFfigJS4rNUQ7MNxRKf6fHKAGe38on24G8luWv66Lzmq oayebV7fV5rGzCgDqgonaKpLwoDeZrTUoucBvwWdQfKt7bGegPFeLLSpY5Dv2Y7S/IX5 sRve03h/2elVDWAbpZd4kjouyY+NGmIj589bsQwnv4eL62Op1y+kYMc1azDpS5ASgmmI 5XaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ys/bRxQQAHjsYcQ1GVvDgSvxj5MRxdS6PdDowbRghFM=; b=daeOxo5NwEhjBntGtkfKGIKaJXcx6EKF/4nnI+fDDffxSYxpwZXlENS6TG9kNHzsyD Ud2mpFABVCJWuym6MndiEUlwZF++A9WkYpP3cdrPuOrlCljqK+ktW+YaJvaN3Zxg1DAm S30+aJorD9VCWBsrzpIU1/YrkIaAxJMLMotaSeAvxJskfwQgaV/0BLE3n4WhLSddeJdN cFLq03NZMMVNpd8R5bTX5azwx6eyIm7UrOIdleEm2MjtDTt9eLdGlJ3LkO/2Azt2lkqU g8hwY/MA7/0iy76P0L4MFHXZlGRlne7FXjfl/BZO66XlNRCeWt/y8ZLSIQNzeSMgJE6X 5Ubw== X-Gm-Message-State: ABUngvf1UNM0vUD63bnqNsJvazLXs9E9uOTIv+MepNWj8KMVI3zrn7Zqat8ndTpxAzCMBMXV4+wwYhN79RxzUA== X-Received: by 10.129.125.215 with SMTP id y206mr1410115ywc.234.1479366919761; Wed, 16 Nov 2016 23:15:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Wed, 16 Nov 2016 23:14:39 -0800 (PST) In-Reply-To: <8C67E8BB-B230-4C84-A890-C57614FF8A46@esat.kuleuven.be> References: <2d2ba626-0b5d-590f-efb7-e4ad30b5608b@esat.kuleuven.be> <201611081626.03635.davemgarrett@gmail.com> <8C67E8BB-B230-4C84-A890-C57614FF8A46@esat.kuleuven.be> From: Eric Rescorla Date: Thu, 17 Nov 2016 16:14:39 +0900 Message-ID: To: Roel Peeters Content-Type: multipart/alternative; boundary=001a11492dfabee41b054179f360 Archived-At: Cc: Jens Hermans , "tls@ietf.org" Subject: Re: [TLS] COSIC's look on TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 17 Nov 2016 07:15:23 -0000 --001a11492dfabee41b054179f360 Content-Type: text/plain; charset=UTF-8 This paragraph refers to the anti-downgrade mechanism described in 4.1.3. -Ekr On Wed, Nov 9, 2016 at 6:56 AM, Roel Peeters wrote: > Hi Dave, > > We are wondering because of this piece of text from the RFC EDITOR just > above paragraph 4.1.4 on Hello Retry Request: > > RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of draft > versions (see Section 4.2.1.1) of this specification SHOULD NOT implement > this mechanism on either client and server. A pre-RFC client connecting to > RFC servers, or vice versa, will appear to downgrade to TLS 1.2. With the > mechanism enabled, this will cause an interoperability failure. > Best, > Roel > > On 8 Nov 2016, at 22:26, Dave Garrett wrote: > > On Tuesday, November 08, 2016 09:55:36 am Roel Peeters wrote: > > we are also wondering whether or not the Hello Retry Request will be > included or omitted in the standard. Leaving it out will make TLS 1.3 > vulnerable again to downgrade attacks ... > > > Why are you wondering about this? HRR is in the specification and there > has been no discussion to remove it. > > > Dave > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11492dfabee41b054179f360 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
This paragraph refers to the anti-downgrade mechanism desc= ribed in 4.1.3.

-Ekr


On Wed, Nov 9, 2016 at 6:56 AM, = Roel Peeters <roel.peeters@esat.kuleuven.be> wrote:

Hi Dave,

We are wondering because of this piece of text from the RFC= EDITOR just above paragraph 4.1.4 on Hello Retry Request:

RFC EDITOR: P= LEASE REMOVE THE FOLLOWING PARAGRAPH Implementations of draft versions (see= Section 4.2.1.1) of this specification SHOULD NOT implement this mechanism on either=20 client and server. A pre-RFC client connecting to RFC servers, or vice=20 versa, will appear to downgrade to TLS 1.2. With the mechanism enabled,=20 this will cause an interoperability failure.

Best,
Roel

On 8 Nov 2016,= at 22:26, Dave Garrett <davemgarrett@gmail.com> wrote:

O= n Tuesday, November 08, 2016 09:55:36 am Roel Peeters wrote:
we are also wondering whether or not the Hello Retry Request= will be
included or omitted in the standard. Leaving it out will make T= LS 1.3
vulnerable again to downgrade attacks ...

Why= are you wondering about this? HRR is in the specification and there has be= en no discussion to remove it.


Dave
=


___________________________________________= ____
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a11492dfabee41b054179f360-- From nobody Thu Nov 17 06:59:07 2016 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 6064B1295CA for ; Thu, 17 Nov 2016 06:59:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=delignat-lavaud.fr 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 9oZvS86VsCXG for ; Thu, 17 Nov 2016 06:59:04 -0800 (PST) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (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 E6FC81294AF for ; Thu, 17 Nov 2016 06:59:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=BL1PFKSt1XFYQFwxMOCrPX9ykERki2T6/9IOxhNHvRA=; b=BvxpAn/2lek2OdeGgf7cL3sELj Nl+9FYbPJIn13Kdp8zgG5UIgfMeQtHCxaprim25cbOcfBmMhDOyz7C5uzXtpoVPep631TsjQMEtVz j111+8RQEFrwFwPHqVYyTPL1oad9e2LDMxutdYvN1RENdZwtia8xUYJcmouRSWi5na3YcYG+2/rwF HLvYK9r6J2X9BXCw5GgJNkyePdx0dkhgWm63koEHmkwZUkIYT9Nf7znRA5GqLCrGjw/Yguf3wY8i/ O+3S6g5CDuFH003vKwyRamg9O4sWS0QQLp5bA3CjRL++0UuqPEyFj1MY84SBDe/1W1a3E+nJ/6pOX eg4IWeBg==; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpa (envelope-from ) id 1c7O9T-0001tc-Qw ; Thu, 17 Nov 2016 15:58:59 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 17 Nov 2016 14:58:58 +0000 From: Antoine Delignat-Lavaud To: Ilari Liusvaara Organization: Microsoft Research In-Reply-To: <20161115153555.GA7882@LK-Perkele-V2.elisa-laajakaista.fi> References: <4D79E074-6231-4CDD-88A0-2E8EBEA1BCA5@gmail.com> <20161115153555.GA7882@LK-Perkele-V2.elisa-laajakaista.fi> Message-ID: <873492101dd071c361b12de270fe166e@delignat-lavaud.fr> X-Sender: antoine@delignat-lavaud.fr User-Agent: Roundcube Webmail/1.2.2 X-Virus-Checked: False Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Point validation in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 17 Nov 2016 14:59:06 -0000 Le 2016-11-15 15:35, Ilari Liusvaara a écrit : > On Tue, Nov 15, 2016 at 05:02:24PM +0900, Yoav Nir wrote: >> I think the performance enhancement (in terms of handshakes per >> second) >> that you get by reusing ephemeral keys is so great, that we have to >> assume people will do it. You don’t have to keep the keys >> indefinitely. >> It’s fine to generate a new key every second or ten seconds or so. >> >> Which makes running the point validation all the more important. > > There's two main reasons for point validation: > > 1) Preventing leaking of the secret exponent. > 2) Preventing key collisions from low-order points. > > TLS 1.3 isn't vulernable to 2) like TLS 1.2 and below are (without > EMS). > > X25519/X448 have been explicitly designed to resist 1). > > If you want to prevent using low-order points for some reason, there is > a handy trick: Check if the output of X25519/X448 is all zeroes or > not, and abort if it is. There is an unfortunately common mis-conception that X25519 doesn't need point validation for Diffie-Hellman which comes from the original PR of Bernstein et al. Curve25519 has an order 8 subgroup that can be used to do key collisions and transcript synchronization attacks (see III.B.2 in [1]). The proper validation is to exclude 0, 1, 325606250916557431795983626356110631294008115727848805560023387167927233504, 39382357235489614581723060781553021112529911719440698176882885853963445705823, 2^255 - 19 - 1, 2^255 - 19, 2^255 - 19 + 1, 2^255 - 19 + 325606250916557431795983626356110631294008115727848805560023387167927233504, 2^255 - 19 + 39382357235489614581723060781553021112529911719440698176882885853963445705823, 2(2^255 - 19) - 1, 2(2^255 - 19), and 2(2^255 - 19) + 1. Without this validation, any one peer of the connection can (mostly) control the session key, which is mitigated in TLS 1.3 but still an undesirable property in any compound authentication setting. Best, Antoine [1] http://antoine.delignat-lavaud.fr/doc/ndss15.pdf From nobody Thu Nov 17 08:13:58 2016 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 E229F12948A for ; Thu, 17 Nov 2016 08:13:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=delignat-lavaud.fr 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 BrhdBx5Wh7cp for ; Thu, 17 Nov 2016 08:13:53 -0800 (PST) Received: from argon.maxg.info (argon.maxg.info [IPv6:2001:41d0:2:7f22::1]) (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 570BA12940C for ; Thu, 17 Nov 2016 08:13:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=delignat-lavaud.fr; s=dkim; h=Message-ID:References:In-Reply-To:Subject:Cc: To:From:Date:Content-Transfer-Encoding:Content-Type:MIME-Version; bh=aY2ZuDmXpDqRxMWhAKetTfnXeD8wEZ1FW3i7ozYgqv0=; b=SwSrDNnxypqmdo98qBZhiVKeDo mBlbFKo7DNL0r9zcGpkqIQEvGI+DwAdaESInt1pu+nNXAN1IVEL39eL7YIbPXkWJ7HX8EEsADyzYC yeLv39GCvo2eaa0etVv4NqoRABMQUgVObwK3MONEEATDGTPoJqtdvDRc/JGZm92q0hX70Gn31jyDz ptaRK9yeQMlXC07J8BqTnFW+7kZ5xpkUmprPZ0jwn4nib8iPr3i+npOBovQMD3TyJMmI0PNeQU5Kd Q5m9uUGuc/4SomAeJ7yI9DjtmPxKtRtyY45H7C5BRXj1WtMS1RBX/eh/Fxi/EIaCUjsuTzLHWHCXM Jh/Naw/A==; Received: from localhost (authenticated.user.IP.removed [::1]) by argon.maxg.info with esmtpa (envelope-from ) id 1c7PJu-0000iQ-5u ; Thu, 17 Nov 2016 17:13:50 +0100 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Thu, 17 Nov 2016 16:13:49 +0000 From: Antoine Delignat-Lavaud To: Ilari Liusvaara Organization: Microsoft Research In-Reply-To: <873492101dd071c361b12de270fe166e@delignat-lavaud.fr> References: <4D79E074-6231-4CDD-88A0-2E8EBEA1BCA5@gmail.com> <20161115153555.GA7882@LK-Perkele-V2.elisa-laajakaista.fi> <873492101dd071c361b12de270fe166e@delignat-lavaud.fr> Message-ID: <3348e9a0ee34a9b10e87c8120c5885ca@delignat-lavaud.fr> X-Sender: antoine@delignat-lavaud.fr User-Agent: Roundcube Webmail/1.2.2 X-Virus-Checked: False Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Point validation in 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 17 Nov 2016 16:13:56 -0000 Le 2016-11-17 14:58, Antoine Delignat-Lavaud a écrit : > Le 2016-11-15 15:35, Ilari Liusvaara a écrit : >> On Tue, Nov 15, 2016 at 05:02:24PM +0900, Yoav Nir wrote: >>> I think the performance enhancement (in terms of handshakes per >>> second) >>> that you get by reusing ephemeral keys is so great, that we have to >>> assume people will do it. You don’t have to keep the keys >>> indefinitely. >>> It’s fine to generate a new key every second or ten seconds or so. >>> >>> Which makes running the point validation all the more important. >> >> There's two main reasons for point validation: >> >> 1) Preventing leaking of the secret exponent. >> 2) Preventing key collisions from low-order points. >> >> TLS 1.3 isn't vulernable to 2) like TLS 1.2 and below are (without >> EMS). >> >> X25519/X448 have been explicitly designed to resist 1). >> >> If you want to prevent using low-order points for some reason, there >> is >> a handy trick: Check if the output of X25519/X448 is all zeroes or >> not, and abort if it is. > > There is an unfortunately common mis-conception that X25519 doesn't > need point validation for Diffie-Hellman which comes from the original > PR of Bernstein et al. Curve25519 has an order 8 subgroup that can be > used to do key collisions and transcript synchronization attacks (see > III.B.2 in [1]). The proper validation is to exclude 0, 1, > 325606250916557431795983626356110631294008115727848805560023387167927233504, > 39382357235489614581723060781553021112529911719440698176882885853963445705823, > 2^255 - 19 - 1, 2^255 - 19, 2^255 - 19 + 1, 2^255 - 19 + > 325606250916557431795983626356110631294008115727848805560023387167927233504, > 2^255 - 19 + > 39382357235489614581723060781553021112529911719440698176882885853963445705823, > 2(2^255 - 19) - 1, 2(2^255 - 19), and 2(2^255 - 19) + 1. Without this > validation, any one peer of the connection can (mostly) control the > session key, which is mitigated in TLS 1.3 but still an undesirable > property in any compound authentication setting. I misunderstood your message, if you check the output of the multiplication with the peer public key rather than the public key itself, checking for 0 is indeed the easiest (and safe) check to perform. Antoine From nobody Thu Nov 17 15:01:56 2016 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 DAB7C1296F2 for ; Thu, 17 Nov 2016 15:01:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 GZ_mcqq4Ooal for ; Thu, 17 Nov 2016 15:01:53 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1624B1294F4 for ; Thu, 17 Nov 2016 15:01:52 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 30B418C0EBF6; Thu, 17 Nov 2016 23:01:46 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAHN1m2E015701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2016 23:01:50 GMT Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uAHN12tm003646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 18 Nov 2016 00:01:47 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.191]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0301.000; Fri, 18 Nov 2016 00:01:25 +0100 From: "Fossati, Thomas (Nokia - GB)" To: "Kraus Achim (INST/ESY1)" , "tls@ietf.org" Thread-Topic: Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header Thread-Index: AQHSP/M+2CTuxcF2xkKqMlv1PL9L5aDdvF0A Date: Thu, 17 Nov 2016 23:01:24 +0000 Message-ID: References: <1479128315.2624.62.camel@redhat.com> <058f1681-9ecf-22db-1b88-2313491c7b72@cs.tcd.ie> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-ID: <6BAB722F9F0BBC4EA79A1CA6A1E13464@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 17 Nov 2016 23:01:55 -0000 Hi Achim, On 16/11/2016 10:21, "TLS on behalf of Kraus Achim (INST/ESY1)" wrote: >I'm still wondering, why the "clashing" calculations (section 4) are only >based on the number of clients and not also on the length of the hash >chain. I guess you are right. The left column should say "sessions x window_size". From nobody Thu Nov 17 15:13:27 2016 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 3A1B71293EB for ; Thu, 17 Nov 2016 15:13:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 jVoNfBMdGXeL for ; Thu, 17 Nov 2016 15:13:24 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 58E6A1293E1 for ; Thu, 17 Nov 2016 15:13:24 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id x190so242055412qkb.0 for ; Thu, 17 Nov 2016 15:13:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=1c51XtFAVH3otoYwlVXVYM7VIrkztRiDvN6k+Knzn9E=; b=PHEubq4LCccs3fHMRbA00R7AMyLmfjxW0c1X9aHBK1yzkbT+qSQ1apHA6WPqBZrzvj TbfT4Q9m5kHtEsW5pNS3Cm06nAFTLnNotHM9Hoe9NAiOYcSmhHKoU0P9Q9hY+MNC4ITm aEUZ8JCzAD6p0ytewj0KMoNt2wDFK9Mu/2a6c= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=1c51XtFAVH3otoYwlVXVYM7VIrkztRiDvN6k+Knzn9E=; b=ZuVWNEDsunaHu3lFJMewg6LQnDve19rUKJvmfe0hepHPXMMLQDSe9JN60Itj2CP0+t AR/EfGOXLM/11NKWKIBnMINve/ayl6cjg+DGaKt/8f1LgDOxvBbVZXBprSvsCwTNrA1+ Z/VLf3cJjMu/RIn7r4dP+uFM/C6gsI4ecn3xX2mMnLHaxIiIYqmScPKGnb2iON/F3/cl Osub5TMAPlx0rnmeHHHxw+v5jtAYkidR+DsRUs54C7H7Fvk6na4kIhPxRK9AYe6GZn2A rgk5YhL1SbN7p3ypevyXB/HAwkH2tqBTc6Xv3pn8ylD7ZapwQ/yfyJqBBd9cgnwf2N6r BHFw== X-Gm-Message-State: AKaTC03sHp7CN6N3Y0XZTuLfKUjgWbFLAha2AgefNGbpD1YkRY0vHUdicD2VEQcPwyCTGw== X-Received: by 10.55.114.70 with SMTP id n67mr7377999qkc.185.1479424403332; Thu, 17 Nov 2016 15:13:23 -0800 (PST) Received: from ?IPv6:2001:67c:370:144:2df0:acb9:f006:bf50? ([2001:67c:370:144:2df0:acb9:f006:bf50]) by smtp.gmail.com with ESMTPSA id q65sm2632686qki.20.2016.11.17.15.13.21 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Nov 2016 15:13:22 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <7071CA02-25D9-4C80-BE08-DC7C22BF8F93@sn3rd.com> Date: Fri, 18 Nov 2016 08:13:00 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <4D05C726-D621-4E09-B509-04E7C63FA839@sn3rd.com> References: <7071CA02-25D9-4C80-BE08-DC7C22BF8F93@sn3rd.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Call for agenda items @ IETF 97 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 17 Nov 2016 23:13:26 -0000 I=E2=80=99ve uploaded the slides for Friday as well as a revised WG = Chair Slide deck (version 5), which reflects the revised agenda based on = presentations that got moved to Wednesday. spt > On Nov 15, 2016, at 08:20, Sean Turner wrote: >=20 > Please note that I=E2=80=99ve been uploading the presentations as = I=E2=80=99ve been getting them; I=E2=80=99m embedding links in the chair = slides to the presenters slides. The chair slides are up to revision 4 = (in case you=E2=80=99ve downloaded them earlier). Still waiting on a = couple. >=20 > Note that Martin will have no slides for the Example Handshake Traces = in TLS 1.3 agenda item. >=20 > spt >=20 >> On Oct 24, 2016, at 00:13, Sean Turner wrote: >>=20 >> The final IETF 97 agenda is out: >> https://datatracker.ietf.org/meeting/97/agenda.html >>=20 >> Please note that there are TWO tls sessions: >> 1. Tuesday @ 15:50-18:20 in Park Ballroom 1 >> 2. Friday @ 09:30-1130 in Grand Ballroom 2 >>=20 >> spt >>=20 >>> On Oct 18, 2016, at 14:07, Sean Turner wrote: >>>=20 >>> The preliminary IETF 97 agenda is out: = https://datatracker.ietf.org/meeting/97/agenda.html. We=E2=80=99re = currently scheduled for Tuesday @ 15:50-18:20 in Park Ballroom 1. >>>=20 >>> Please send in agenda requests. But, please note that TLS = 1.3-related issues and WG drafts will be given a priority during the = sessions. We=E2=80=99re also going to give preferential treatment to = drafts that generated discussion on the list. >>>=20 >>> Cheers, >>>=20 >>> J&S >>=20 >=20 From nobody Thu Nov 17 16:28:04 2016 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 DE96C129544 for ; Thu, 17 Nov 2016 16:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 uwJUK6-nTPOF for ; Thu, 17 Nov 2016 16:28:01 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 CB4181294FF for ; Thu, 17 Nov 2016 16:28:00 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n204so244473704qke.2 for ; Thu, 17 Nov 2016 16:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=clxbPD2Cdfb292tDyaw+8N7KNMG3WT85zJ14UKIHnz0=; b=HkYD5GjKaED3tiiYLKxjVrJ/r6WHi0x0q13vJzK1qneBOeuTzC4N0InAxxfHAsRHWg oj/TGTtENJ162HwU3YqUWVWimsWWCJlN7D/hWA37K6637XL+sPljoITyvjo3kPZnzRfo Q3eFcJiAKQhcAvP+kf/JA8Nk3wQ4Arn9umhuA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=clxbPD2Cdfb292tDyaw+8N7KNMG3WT85zJ14UKIHnz0=; b=hbXpd6F+nrJvnn+9iIdeKf3JBvnl7i2Q9+yZP41Du03J7rWTo+ocaB3LVcQzUnj0L0 G0Kb101tF215+lWRZdWehEkIKYUm8p9NRLsDB4PGoNVMLariRXNjckpTjby3mrLFMudW apdD65/7G+ys66vxlLXNzTdDaTsoXBz8gGZSNi+H5jXwwrfydThWRoHTKRnV4qmDavt1 LckH1USzkYf6r+VpJFSLzhGjlHiqY9HhQd3uFkO/vqNDELCTHIsHznvx+S40hcWU6D5y onOD+C3ard1pNURFl/cu39mF+ihRfR6Rkgyx3lStz6mhb9fZpXGElAsmTR24XcjCu6Kj EpuA== X-Gm-Message-State: AKaTC01pR62w+hIM32ilfsGuT534Ailk4WBbRMeb57h8U/EHYNuvtYacWSqCwMxawEFQXw== X-Received: by 10.55.164.5 with SMTP id n5mr7139764qke.307.1479428879804; Thu, 17 Nov 2016 16:27:59 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:54:f15f:e656:352? ([2001:67c:370:128:54:f15f:e656:352]) by smtp.gmail.com with ESMTPSA id 16sm2748448qtn.33.2016.11.17.16.27.58 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Nov 2016 16:27:59 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <4D05C726-D621-4E09-B509-04E7C63FA839@sn3rd.com> Date: Fri, 18 Nov 2016 09:27:25 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <958CC919-58CB-45C6-9C0D-2AE5EC664538@sn3rd.com> References: <7071CA02-25D9-4C80-BE08-DC7C22BF8F93@sn3rd.com> <4D05C726-D621-4E09-B509-04E7C63FA839@sn3rd.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Call for agenda items @ IETF 97 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 00:28:03 -0000 New version uploaded v6 is now the current version. spt > On Nov 18, 2016, at 08:13, Sean Turner wrote: >=20 > I=E2=80=99ve uploaded the slides for Friday as well as a revised WG = Chair Slide deck (version 5), which reflects the revised agenda based on = presentations that got moved to Wednesday. >=20 > spt >=20 >> On Nov 15, 2016, at 08:20, Sean Turner wrote: >>=20 >> Please note that I=E2=80=99ve been uploading the presentations as = I=E2=80=99ve been getting them; I=E2=80=99m embedding links in the chair = slides to the presenters slides. The chair slides are up to revision 4 = (in case you=E2=80=99ve downloaded them earlier). Still waiting on a = couple. >>=20 >> Note that Martin will have no slides for the Example Handshake Traces = in TLS 1.3 agenda item. >>=20 >> spt >>=20 >>> On Oct 24, 2016, at 00:13, Sean Turner wrote: >>>=20 >>> The final IETF 97 agenda is out: >>> https://datatracker.ietf.org/meeting/97/agenda.html >>>=20 >>> Please note that there are TWO tls sessions: >>> 1. Tuesday @ 15:50-18:20 in Park Ballroom 1 >>> 2. Friday @ 09:30-1130 in Grand Ballroom 2 >>>=20 >>> spt >>>=20 >>>> On Oct 18, 2016, at 14:07, Sean Turner wrote: >>>>=20 >>>> The preliminary IETF 97 agenda is out: = https://datatracker.ietf.org/meeting/97/agenda.html. We=E2=80=99re = currently scheduled for Tuesday @ 15:50-18:20 in Park Ballroom 1. >>>>=20 >>>> Please send in agenda requests. But, please note that TLS = 1.3-related issues and WG drafts will be given a priority during the = sessions. We=E2=80=99re also going to give preferential treatment to = drafts that generated discussion on the list. >>>>=20 >>>> Cheers, >>>>=20 >>>> J&S >>>=20 >>=20 >=20 From nobody Thu Nov 17 18:07:38 2016 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 0FFCC128E18 for ; Thu, 17 Nov 2016 18:07:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 0Jv5oV-ydNg2 for ; Thu, 17 Nov 2016 18:07:34 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 6FE91129604 for ; Thu, 17 Nov 2016 18:07:34 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id n204so246725332qke.2 for ; Thu, 17 Nov 2016 18:07:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=vArucL74t1HI5tgXj/gUZiQW6P1g6R6jxWQOZuaS5is=; b=Koo0aoBawP5C+lZj0lTT4v+d4BPSQvJiw2NnHHUzxPB2KWoVoW640O6hWWAWvFkZvl b6wkOnfjl/9B40JnbRcfd5FnE72/XVUceyVnp/yu8OYupV8uw/Lpdusow1IiMZ/KhLCh yObxWZh8zKO8tbzlW+UkSsrb7ThIKifYKqw/E= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=vArucL74t1HI5tgXj/gUZiQW6P1g6R6jxWQOZuaS5is=; b=esp5G0HibSmqn8H/G6j0nB9nQhA99qFQKpd7xc6OEVTc0tfpTGboWc/wMiRDOygG2S L81v3qNvBQZYfWmVfBApSBSun91vDlX2lvFYFSM/Y6K9DD//e+0zjVGnSmQ2ax+QvDBi HYFzWKduS5j99iUt8hz31TyoN9sNR8WF08ecgUadg5oyAydpq/QOPnz8L1jUsnAOngBA 2xjtlLfqHbIKnOPS29zXraL9G4yV5pxH1cr4FoXgffrtAFpW5kDFrZ8uh5q8UbtCYDkm V2669FKbhtg0imQjbOsEqS49ZCLEajk5CnL/vtTZpRw80gjCLbK3iTUAVMUkp6FPNptA WZVg== X-Gm-Message-State: AKaTC02gDM3QY339f0ne9fusq3veSoTb5gcRPCQi9evvPC61dLEhaPngAFhcRIEnRi7AKw== X-Received: by 10.55.64.79 with SMTP id n76mr7664586qka.178.1479434853533; Thu, 17 Nov 2016 18:07:33 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:54:f15f:e656:352? ([2001:67c:370:128:54:f15f:e656:352]) by smtp.gmail.com with ESMTPSA id p19sm2942114qte.23.2016.11.17.18.07.32 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Nov 2016 18:07:33 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <13231BFA-5D9B-4706-A7D8-F6697631F625@sn3rd.com> Date: Fri, 18 Nov 2016 11:07:12 +0900 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-ecdhe-psk-aead X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 02:07:36 -0000 This is the working group last call for the "ECDHE_PSK with AES-GCM and = AES-CCM CSs for TLS" draft available at = http://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/. Please = review the document and send your comments to the list by 9 December = 2016.=20 Thanks, J&S= From nobody Thu Nov 17 18:13:22 2016 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 5585F1299EA for ; Thu, 17 Nov 2016 18:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 47YyvauQud5i for ; Thu, 17 Nov 2016 18:13:20 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 204B71299E6 for ; Thu, 17 Nov 2016 18:13:19 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id n21so246629578qka.3 for ; Thu, 17 Nov 2016 18:13:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=y6u80rhdqY+6EBnsmkq5+eMTSzGZZeLtrvXagg7Ehao=; b=jrh7kJtwiU/7tBwY+zRx1MpMGBrbLRYV24Gw2DtlgNDAvBpCJt6BguiRX6lvN08puD Qgm1OnAXzyDnoyZcuu65wLjUxEiLgYkiDv5kL0+I65pLz6tqG/KQ8I9cYjwEsautFl9n erAC38WS9WkHpjnX4Ofgc6SedPve8COi4j0Ek= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=y6u80rhdqY+6EBnsmkq5+eMTSzGZZeLtrvXagg7Ehao=; b=jXTfjl8RNaTzFgaRdEOiUnr1fOHPp8eDFJ0ODuDe1DuqbTHTGGYZ/M3TVcs2U8uq2X JIVaR3XP34KGTkOAsQfDUWSN2HVReQEOLGWfux/RaMsiEnMNkMUHfzx3ZNRir662KKuV f7wByYKN3dcgtTgh7O/Zpo3xp7Umqa9zZCDJc1494c2s2S78jdeXaiOHieZVNt4mo7xL w/2Lqvc4ytz95W4Fhtu165Px+AQ3yquc66Pi8+3RJgiS2VIkcqH35Z1aOHosZZ24e4b7 WUfdUaRlRPsquUY8jxej6v+UnxfpbszLch0sFeJZQoA1rFKzzMTlmG6n+tx6xFf+xUjh hzgw== X-Gm-Message-State: AKaTC02ZBqDI/v06PJf/6WyB56q15NTI3S0ciHqnLwEYjks+3crPYEZpmXhf9NMbl8QEMg== X-Received: by 10.55.145.65 with SMTP id t62mr7157720qkd.191.1479435197261; Thu, 17 Nov 2016 18:13:17 -0800 (PST) Received: from ?IPv6:2001:67c:370:128:54:f15f:e656:352? ([2001:67c:370:128:54:f15f:e656:352]) by smtp.gmail.com with ESMTPSA id f7sm394191qtf.48.2016.11.17.18.13.15 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 17 Nov 2016 18:13:16 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 18 Nov 2016 11:12:48 +0900 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 02:13:21 -0000 At IETF 97, the chairs lead a discussion to resolve whether the WG = should rebrand TLS1.3 to something else. Slides can be found @ = https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr= 612-01.pdf. The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this = decision on the list so please let the list know your top choice = between: - Leave it TLS 1.3 - Rebrand TLS 2.0 - Rebrand TLS 2 - Rebrand TLS 4 by 2 December 2016. Thanks, J&S= From nobody Thu Nov 17 18:41:38 2016 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 11B391299EC for ; Thu, 17 Nov 2016 18:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aooQDvrZa4Wb for ; Thu, 17 Nov 2016 18:41:35 -0800 (PST) Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (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 6E6A4128E18 for ; Thu, 17 Nov 2016 18:41:35 -0800 (PST) Received: by mail-pg0-x22f.google.com with SMTP id 3so97841172pgd.0 for ; Thu, 17 Nov 2016 18:41:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C2r7vWDhuajw3vGuB5TvMQYCG54vM5W43KGUd3qJ++0=; b=ewrIrnOSbHYFVt/49kmZ8VmDBKH/i2S05aQ61HwHgBtpdF70GS74CGPFTT/w7/RtYN XScuh2o5goUBmp1Xw5y5rU2YMQdPbbBDIesMh8W+7Gv3KMCmoOrOVzJL7mfXQEhMrmRq THirv6QcmSouCDLcwsmR0XdbvU66BW/jJkMagW1MIKcwH1Y6RZvOmHKCW5sstCQR0i3I zrzUDCYePKz9JBOLXQFjra4i8WmeZExtaI44d4LpkCF6oJsm+ylcT+pH8V8s+tIENp+X 6DohKPtrQATEdJ8fYt0nFa5O/HSmzK53freffBrUrUatVOpOAsEDg83VE0d29JIIzbok G7xA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=C2r7vWDhuajw3vGuB5TvMQYCG54vM5W43KGUd3qJ++0=; b=EXgJBCosQyhN7/LnaaubsjRp5xxJIoPYv1MQRlApdf+YCOPysymdKQiAL2pDOQfU2y eoInkOUAAJAdlFwsvPoBDDy94lVok23yhAP+AToNYV7NExGpq5T+zxyMt+lbxcG4zfEW otkChAl9DtlFDQQwPTc3Gil5eUlpN6wbynR4VJZcMfDpmhm0n4+79Opvkqnkf3zsvZQB nVc+u1OdaT9bJQx8viXpWLZ66AmQv8FMXa4CDv4Uxb2DRcvtSKZ40ACjC15e0n8qy4v7 Lz1rIVaYCG6YYG0HpIWNa6+cZOhIMlxhUz9O9YFQVP/iyDhZfjySlDpkj4aAYp227stO jm1Q== X-Gm-Message-State: ABUngvfoEXSkeRdmMpJWne0XOz2BQSf7gSRKCYX/y5ZGcSxqv6hzbNiRtO7z7vLTUiObmA== X-Received: by 10.98.74.18 with SMTP id x18mr8717599pfa.58.1479436894937; Thu, 17 Nov 2016 18:41:34 -0800 (PST) Received: from [10.56.26.202] ([116.84.110.9]) by smtp.gmail.com with ESMTPSA id t21sm11652761pfa.1.2016.11.17.18.41.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 18:41:34 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: Date: Fri, 18 Nov 2016 11:41:31 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Sean Turner X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 02:41:37 -0000 Bleh. Can=E2=80=99t we get AOL to release the SSL trademark so that we = can call it SSLv4?=20 I hummed for TLS 4, so I=E2=80=99ll stay consistent: TLS 4. Yoav > On 18 Nov 2016, at 11:12, Sean Turner wrote: >=20 > At IETF 97, the chairs lead a discussion to resolve whether the WG = should rebrand TLS1.3 to something else. Slides can be found @ = https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr= 612-01.pdf. >=20 > The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this = decision on the list so please let the list know your top choice = between: >=20 > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 >=20 > by 2 December 2016. >=20 > Thanks, > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Nov 17 19:11:49 2016 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 41389129A07 for ; Thu, 17 Nov 2016 19:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nrgT6QyRub3J for ; Thu, 17 Nov 2016 19:11:46 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 16497129A0C for ; Thu, 17 Nov 2016 19:11:45 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id 20so160424604uak.0 for ; Thu, 17 Nov 2016 19:11:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=W9wX4LxBKMkEQOME+WgZOb1yNE5m1FlC4Lz3FKFD40Y=; b=RB6/PSPM2K6mVKZz1TC9wpLA+ot7v7FrBusUh4g1vV85RNPNTq8SE0TChkiFt6Zwwr JVTOGb+fYKNyQLKFEh/pFwWK+Z9URP9XzJh3OqKozl35rJeAO5kl5u9YCnZWHnxBsDsU n7l2tp+MVm1scdSriA2gc5o3NQuqQlN6PeayxStpcjX1hE/O5LHsHiA6EPmzoqNFDsfC M73n1L7+4GRoYiGIZzwCFHlGX/4hxLx4YJ4/+NWHyDvelhuMll7tZJHXmnXl0nYa5vfA MEg78Hv5qBlWuR4+beBccyP1JHaU+ZJJ9u0OiTsyOrSHeSEfrpy/Zsy3nlgxT5IAaT1C 2FPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=W9wX4LxBKMkEQOME+WgZOb1yNE5m1FlC4Lz3FKFD40Y=; b=gz1lwpdFV9DXeJdD74iFOMFf5HUgCVtzA248Wwomz5KbYq6Emlq3FcXuaWAmvwz9PX biPFrprtscsOSvg5g8QIZTio6twKZQ/4pQVS/Fs5KN47f9eEbPkZNQzZKud+AgLCAWwU zEM7JrULZUx5SG0KnlInYZpZUhUJBHTWzxjFcA4DIS6Z3ozkCdavsibM7UkzjPa2zt6B +AvjJeDmmddDTxAdRnleAoz3n9UlBB3R0Ede2chm9Ijzs/W0cHztF0XFufXi6bTcZh09 B94+LwATYCygBW8N2Bgret5VyUC/EmNcuXDGkQ8iSaaH9TeaCzXTRCGJoFlL9yChqwwb VfaA== X-Gm-Message-State: ABUngvcsB7Syx47kjrGbSqldgbfOVvS5FnmfXl5dqpewQFhHxtPxV94CwrJVss3FAK/uFOzSUHRcsTekxFt9fg== X-Received: by 10.176.0.168 with SMTP id 37mr4569101uaj.16.1479438704209; Thu, 17 Nov 2016 19:11:44 -0800 (PST) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.103.108.65 with HTTP; Thu, 17 Nov 2016 19:11:43 -0800 (PST) Received: by 10.103.108.65 with HTTP; Thu, 17 Nov 2016 19:11:43 -0800 (PST) In-Reply-To: References: From: Erik Nygren Date: Thu, 17 Nov 2016 22:11:43 -0500 X-Google-Sender-Auth: 2X7soaD7tke8xrm97PZKVoOwOJo Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=001a113cf89a6e759b05418aaae3 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 03:11:48 -0000 --001a113cf89a6e759b05418aaae3 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I also prefer TLS 4 but am fine with TLS 1.3 - Erik On Nov 17, 2016 9:41 PM, "Yoav Nir" wrote: > Bleh. Can=E2=80=99t we get AOL to release the SSL trademark so that we ca= n call it > SSLv4? > > I hummed for TLS 4, so I=E2=80=99ll stay consistent: TLS 4. > > Yoav > > > On 18 Nov 2016, at 11:12, Sean Turner wrote: > > > > At IETF 97, the chairs lead a discussion to resolve whether the WG > should rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-rebranding-aka-pr612-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to > not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this > decision on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. > > > > Thanks, > > J&S > > _______________________________________________ > > 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 > --001a113cf89a6e759b05418aaae3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I also prefer TLS 4 but am fine with TLS 1.3

- Erik

=C2=A0


On Nov 17, 2016 9= :41 PM, "Yoav Nir" <yni= r.ietf@gmail.com> wrote:
Bleh. Can=E2=80=99t we get AOL to release the SSL trademark s= o that we can call it SSLv4?

I hummed for TLS 4, so I=E2=80=99ll stay consistent: TLS 4.

Yoav

> On 18 Nov 2016, at 11:12, Sean Turner <sean@sn3rd.com> wrote:
>
> At IETF 97, the chairs lead a discussion to resolve whether the WG sho= uld rebrand TLS1.3 to something else.=C2=A0 Slides can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pd= f.
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not rebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this d= ecision on the list so please let the list know your top choice between: >
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4
>
> by 2 December 2016.
>
> Thanks,
> J&S
> _______________________________________________
> 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
--001a113cf89a6e759b05418aaae3-- From nobody Thu Nov 17 20:16:24 2016 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 E8188129559 for ; Thu, 17 Nov 2016 20:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] 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 pL_n1ulmxyYd for ; Thu, 17 Nov 2016 20:16:21 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (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 3F37C1293FC for ; Thu, 17 Nov 2016 20:16:21 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id q130so249171229qke.1 for ; Thu, 17 Nov 2016 20:16:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xL+0jT1YnMvLL39gJ2R859P3HUMg3unM+5BV59168MQ=; b=OeR30wat3JRTx6J4xZMXAK9BInB0jW5gXCTE9w6Q8RdqbygRe6LOAJatIMH12qiPSP XStCmGu0gTn2Qa/hbFCsZ66RkS9q/ZoNQo5djn6Z9xW03dNMFMuFIb3It9kWPPezry8m Qi9DEgI+DVisCgxXlyw480hCKn7WJai8YOGLtCzoUBzNukoZoj1RfSgLM8SEjXcvUEUr bso0Edo9m+UvEf1NPPE4GpSdTBIyBeJjxXsnXLq/9vXEDW7tg7ktmwZtug5HLHLr9vo2 jYJ45cWyP1xxHqVYQtn/agBuwBxvquD8YRODvgC+Aya45If8aGM+foOsLop73Kj18jZn SsFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xL+0jT1YnMvLL39gJ2R859P3HUMg3unM+5BV59168MQ=; b=kc0luJXk25DPEnZyJlTbwjvENF3tdWOCb8/3cwKQ00BdoSiA7ynJoUXjbkYX9fNc0p OwdjgQv6zVYd2/MBS6jm7yCogiUzvrjjbtQwpulKP45tWnaebwD0hfrHlVf2rIywTV2+ MRDBaM6wt29dWywZMOzpyq+78EqJM5VZ6/bHv+nV3wj44GpyFAFfEafPxrOmQbMtqNfd zH7tFiewA9Hz8zlllBRkWJ/6G9rdoVqp9d3m4EJrWW/hoVXXe1KZc3LgqTf8hI9t4lYz KkLTVYOn6s/7Qd8dnHmaWvBkk0iD00ofz+EuC9AfFXDopbgc6thEd1eYmMUaqjrzi+vS Nz/Q== X-Gm-Message-State: AKaTC00xYzRzRHoIpHAvis5mM0ZfWEC/fY2CYh3ypC876gNyuaq0nYesDvqWCk2Logh+Nobmd+C3k9qnwMcoOVE6 X-Received: by 10.55.18.145 with SMTP id 17mr7664522qks.34.1479442580358; Thu, 17 Nov 2016 20:16:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.169.130 with HTTP; Thu, 17 Nov 2016 20:16:00 -0800 (PST) In-Reply-To: References: From: Nick Harper Date: Fri, 18 Nov 2016 13:16:00 +0900 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a113ac93478063205418b9198 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 04:16:23 -0000 --001a113ac93478063205418b9198 Content-Type: text/plain; charset=UTF-8 I prefer TLS 1.3 but am also fine with TLS 4. On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. > > Thanks, > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113ac93478063205418b9198 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I prefer TLS 1.3 but am also fine with TLS 4.

On Fri, Nov 18, 2016 at = 11:12 AM, Sean Turner <sean@sn3rd.com> wrote:
At IETF 97, the chairs lead a discussion to resolve whethe= r the WG should rebrand TLS1.3 to something else.=C2=A0 Slides can be found= @ https://www.i= etf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-= 01.pdf.

The consensus in the room was to leave it as is, i.e., TLS1.3, and to not r= ebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this decisi= on on the list so please let the list know your top choice between:

- Leave it TLS 1.3
- Rebrand TLS 2.0
- Rebrand TLS 2
- Rebrand TLS 4

by 2 December 2016.

Thanks,
J&S
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a113ac93478063205418b9198-- From nobody Thu Nov 17 21:20:39 2016 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 225251295FA for ; Thu, 17 Nov 2016 21:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXL23-IPqYbC for ; Thu, 17 Nov 2016 21:20:37 -0800 (PST) Received: from mail-vk0-x22d.google.com (mail-vk0-x22d.google.com [IPv6:2607:f8b0:400c:c05::22d]) (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 DE3591293FB for ; Thu, 17 Nov 2016 21:20:36 -0800 (PST) Received: by mail-vk0-x22d.google.com with SMTP id x186so160078726vkd.1 for ; Thu, 17 Nov 2016 21:20:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W3uRHmF1EYkjVY/5JXGiyxWrd/5HpNLr2HwPUiQ7qZs=; b=O+IwDwuZGnteMDK0/rN6EULHB3VrejVXNLZQRtdn0SxViFpiqorbaPfseUFNO5yWX6 eky4h54PHf/6I6uTQMUuoQRM4yxjU35P0Ma1+cAb2Aiuyehj0Or96eLkP3BVSxBzTy+5 UVZ7Q9vqS3S/RsCoFjEhkcxyoO7XJBUz0ylz49ip2KLJfVpgJGJOTbiPwbaDqgYeHYIg SCngaG9M2qfipH81g3U0WMuLKP9KlGoz2GzRdsIOqqpMjqr/kuMDF8OfDQgZPeSfSIzP OIRuHkim6SipmOOb3Yg0kRHmuzRDPOt1FvYKpEkA7zrZQeZ77Ce06mxeL6cn7AA5v2GN ldGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W3uRHmF1EYkjVY/5JXGiyxWrd/5HpNLr2HwPUiQ7qZs=; b=HBPmEkH3MMu9hyiunZkWdZ0/XKsBMucodVwEPWicEpmYZOCosll2A8FigiPmi+8g8c EKlqC+rIQg/pQIU+AyNVaPNdavcKcK2tBpR9TjOBhTGSEgxiziAK/IKdfZDfI9qfNeXb QB+oM3zKC38nolzno9Yn0sEQFAo+uKLYskmHIuVjZxsVmklB344ourehQMZspsr0/qyD Cxb7qk4gjtp7ou651qpi85CZnW20tbR31yZ7amb6GB/p64pMbdqFBK2KqQ7MBxvuFJD9 GAGlvhmqVKU4kyCGhoV1mBB1zzb7s30FBNmDi6qnnGatuLFQg07fzDZJQHG7nWsdWy/p AdFA== X-Gm-Message-State: AKaTC02UpdZz3wkD+sFGpE+lGgDHV7dCv7qRndnNScAAu8y60IdZqWVwDrFeDs8pFr9NvDL8BABnQk2Lhxb+xg== X-Received: by 10.31.98.71 with SMTP id w68mr4370164vkb.20.1479446436040; Thu, 17 Nov 2016 21:20:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.103.28.131 with HTTP; Thu, 17 Nov 2016 21:20:15 -0800 (PST) In-Reply-To: References: From: Tony Arcieri Date: Thu, 17 Nov 2016 21:20:15 -0800 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=94eb2c094e6a48d73205418c7734 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 05:20:38 -0000 --94eb2c094e6a48d73205418c7734 Content-Type: text/plain; charset=UTF-8 I am a big fan of leaving it as TLS 1.3. It feels more like evolution than revolution, even with the addition of 0-RTT. I would like to see a future TLS 2.0, but one that makes fundamental changes which didn't make the cut for 1.3, e.g. moving to OPTLS. -- Tony Arcieri --94eb2c094e6a48d73205418c7734 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am a big fan of leaving it as TLS 1.3.

It feels more like evolution than revolution, even with the addition of 0= -RTT. I would like to see a future TLS 2.0, but one that makes fundamental = changes which didn't make the cut for 1.3, e.g. moving to OPTLS.
<= div>
--
Tony Arcieri
--94eb2c094e6a48d73205418c7734-- From nobody Thu Nov 17 22:04:34 2016 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 7FA64129A23 for ; Thu, 17 Nov 2016 22:04:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 vhU6SLMHbr2r for ; Thu, 17 Nov 2016 22:04:30 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B84C512987A for ; Thu, 17 Nov 2016 22:04:30 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B6D48284B6F; Fri, 18 Nov 2016 06:04:29 +0000 (UTC) Date: Fri, 18 Nov 2016 06:04:29 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20161118060429.GQ26244@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org 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, 18 Nov 2016 06:04:32 -0000 On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 TLS 4 sounds about right to me: * Conveys the substantial protocol changes * Avoids any confusion from SSLv2/SSLv3 bearing higher numbers than TLS 1.x * If someone happens to call it SSLv4 it will not be confusing. * Matches the minor version on the wire protocol Though with this choice, the next version would likely be TLS 5, whether or not it is a major change or just incremental change, I don't think it will going forward be important to convey that some version updates are minor. A non-branching integral sequence feels about right. The only downside I see is that it becomes unclear what to call some future protocol version with a wire protocol major number not equal to 3. My take is that such a protocol would no longer be TLS (it would presumably have an incompatible HELLO and/or record layer format and would not be able to negotiate older protocol versions), so there's likely not much point in calling such a hypothetical beast "TLS". -- Viktor. From nobody Thu Nov 17 22:18:21 2016 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 C97F1129A23 for ; Thu, 17 Nov 2016 22:18:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 serR6h7dTZMw for ; Thu, 17 Nov 2016 22:18:17 -0800 (PST) Received: from mail-it0-x236.google.com (mail-it0-x236.google.com [IPv6:2607:f8b0:4001:c0b::236]) (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 BC8B51298A9 for ; Thu, 17 Nov 2016 22:18:17 -0800 (PST) Received: by mail-it0-x236.google.com with SMTP id c20so13562916itb.0 for ; Thu, 17 Nov 2016 22:18:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=iTjD79qF4up5YgJ1p6v5ThBh7Zm2yvWUijgeeuDu8Gs=; b=BgHpFIIRr3IG/nroZ6A2NYSojrV6xTT/QpaYf4uyrTryjpp4nW73XNSSgPOVzt4Q0x QFP4LhUK3aceFfb5zqpXSeA5R09zAwprHEYxFGQggrIGBihGnGoiecxcBjyJSwvu5VBf UxSQq/68JHnAO915LO+278sOCsLhowLD2zvl0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=iTjD79qF4up5YgJ1p6v5ThBh7Zm2yvWUijgeeuDu8Gs=; b=LkYwOKkZo/50CoQVtvjmO3gCPCtO/4guadmrkD4RXTnygAO3Xrc8RJO/OmeNLaynl3 8DeYdLpNboJ8zbVAFB2A60L96P6mT4r1ixQvP7c7xSFikPryZqiur/Nj+MHlcmjPlxDU iZlrqGN39gvtYRf3V8Gup6nDfIPhz/aVBjT5vKelaurI/s/QKlSNSeDNEB6nMvnjPSVc U/6Zw5gR+iaBbHmvWzvQ6IciocCfdVxi7tSOltfYcFbnEWJ/I89HcHPxHYIAUwz0jlwD L9XJ2CwldyC0QQ19Saj56Z6oEjumKl97MoyLSZznHdYSfVxcCVfSnsSFx290I0YX0R5E jrIQ== X-Gm-Message-State: AKaTC02GeoNmgtPz963QQL09Y6S8wIATv3rGHgj3QIAB6aoMUvZIEERSGqrSg8cXuW4PwIdltgqc3xTxxFPGNiwK X-Received: by 10.107.136.229 with SMTP id s98mr6949240ioi.171.1479449896648; Thu, 17 Nov 2016 22:18:16 -0800 (PST) MIME-Version: 1.0 References: <20161118060429.GQ26244@mournblade.imrryr.org> In-Reply-To: <20161118060429.GQ26244@mournblade.imrryr.org> From: David Benjamin Date: Fri, 18 Nov 2016 06:18:05 +0000 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a113ed55c8ddfac05418d458c Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 06:18:20 -0000 --001a113ed55c8ddfac05418d458c Content-Type: text/plain; charset=UTF-8 I already hummed in the room, but I think it should stay as TLS 1.3. Either of TLS 2 or TLS 4 makes the SSL/TLS silliness worse. One matches SSL 2.0 and the other just makes all this weirder. (Do we really want 2.0 < 3.0 < 1.0 < 1.1 < 1.2 < 4?) TLS 1.3 is the natural next number and doesn't make anything worse. Let's just use it. On Fri, Nov 18, 2016 at 3:04 PM Viktor Dukhovni wrote: > On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote: > > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > > rebrand TLS1.3 to something else. Slides can be found @ > > > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf > . > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > > on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > TLS 4 sounds about right to me: > > * Conveys the substantial protocol changes > * Avoids any confusion from SSLv2/SSLv3 bearing higher numbers than > TLS 1.x > * If someone happens to call it SSLv4 it will not be confusing. > * Matches the minor version on the wire protocol > > Though with this choice, the next version would likely be TLS 5, > whether or not it is a major change or just incremental change, I > don't think it will going forward be important to convey that some > version updates are minor. A non-branching integral sequence feels > about right. > > The only downside I see is that it becomes unclear what to call > some future protocol version with a wire protocol major number not > equal to 3. My take is that such a protocol would no longer be > TLS (it would presumably have an incompatible HELLO and/or record > layer format and would not be able to negotiate older protocol > versions), so there's likely not much point in calling such a > hypothetical beast "TLS". > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113ed55c8ddfac05418d458c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I already hummed in the room, but I think it should stay a= s TLS 1.3. Either of TLS 2 or TLS 4 makes the SSL/TLS silliness worse. One = matches SSL 2.0 and the other just makes all this weirder. (Do we really wa= nt 2.0 < 3.0 < 1.0 < 1.1 < 1.2 < 4?)

TLS = 1.3 is the natural next number and doesn't make anything worse. Let'= ;s just use it.

On Fri,= Nov 18, 2016 at 3:04 PM Viktor Dukhovni <ietf-dane@dukhovni.org> wrote:
On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote:=

> At IETF 97, the chairs lead a discussion to resolve whether the WG sho= uld
> rebrand TLS1.3 to something else.=C2=A0 Slides can be found @
> https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebrandin= g-aka-pr612-01.pdf.
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not
> rebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this = decision
> on the list so please let the list know your top choice between:
>
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4

TLS 4 sounds about right to me:

=C2=A0 =C2=A0 * Conveys the substantial protocol changes
=C2=A0 =C2=A0 * Avoids any confusion from SSLv2/SSLv3 bearing higher number= s than TLS 1.x
=C2=A0 =C2=A0 * If someone happens to call it SSLv4 it will not be confusin= g.
=C2=A0 =C2=A0 * Matches the minor version on the wire protocol

Though with this choice, the next version would likely be TLS 5,
whether or not it is a major change or just incremental change, I
don't think it will going forward be important to convey that some
version updates are minor.=C2=A0 A non-branching integral sequence feels about right.

The only downside I see is that it becomes unclear what to call
some future protocol version with a wire protocol major number not
equal to 3.=C2=A0 My take is that such a protocol would no longer be
TLS (it would presumably have an incompatible HELLO and/or record
layer format and would not be able to negotiate older protocol
versions), so there's likely not much point in calling such a
hypothetical beast "TLS".

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a113ed55c8ddfac05418d458c-- From nobody Thu Nov 17 23:27:13 2016 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 9B83412959C for ; Thu, 17 Nov 2016 23:27:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LuTUKF2cc37v for ; Thu, 17 Nov 2016 23:27:11 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 89691129401 for ; Thu, 17 Nov 2016 23:27:11 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id p16so149654924qta.0 for ; Thu, 17 Nov 2016 23:27:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=pRrmC2WxId7lrFj9RmZ6HL3W0euP8vCabjv+Dvs+uAo=; b=d7Ap7gFMZH6ZafBoR24HXZNQo9kbQYY8Oc5QVzzk+VI4PEUCF7xWm44VZYTW0dhBFc 9xJaIjCNnx+cdMCQrig9TwVNwRjV2fGgctf110r1wx/kCTh40WWSub7zWjEz55Zc+zl3 6gqriCRPC04GlLjpHO7z+UKaKl4qt/ZUQA5mg56lK7VO/HawcuRpS1C/EVEm+2A5PywR Fd1GwN+OQ39T2riJeryYj4ZlAWhL22Uf6iJTQq11W3d7/mp05I/5T650DwIJfffVVEeV rhq4Ur6tP73/r8gwSUWQwF8yiZE0MYQms+WCrHzDSQ3nOlY6Zb/S7eFpV/umD3AFdhae Cflg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=pRrmC2WxId7lrFj9RmZ6HL3W0euP8vCabjv+Dvs+uAo=; b=O1bMuPVklCxNt/mwcgbNO0TRrt7NKEP9/2kCOY3awj0GTgvoi+349caDdGGe6tovEp TbPdiB4xmKl/e+vb47GA6Kpydf2w+Ly0uuR0eGyrqNpCL0Q5INKUaeHxHt+QZOwIDeDI QSKr/JQbDuGvI6OCcIy5cl2RoJa8bvVi7cdgAqxB5+2jB2hWtpinlx+TO7dfklYDUIU9 r076NBj3mqlEmdt/sz9ajp3jCpxPQQ1xxV1cntVEEiBsbeqeYNseJecrFyQzzM1R6xf8 HKuI5R2z4aPu+PhfJsu9nUYi5RjCxkHcA1WGrJWZSnKIH+hd/fZuYfa5AExvaFRX+dPM Wo1Q== X-Gm-Message-State: AKaTC00vBdYP0IvRTIfw4hdmz9OVo3TH2DDHcYWvf52RugnmE3pmd2juv8ATfGKygeFlzA== X-Received: by 10.237.47.227 with SMTP id m90mr5376877qtd.120.1479454030274; Thu, 17 Nov 2016 23:27:10 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-27-43.phlapa.fios.verizon.net. [71.175.27.43]) by smtp.gmail.com with ESMTPSA id k16sm3423369qtc.22.2016.11.17.23.27.09 (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 17 Nov 2016 23:27:09 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Fri, 18 Nov 2016 02:27:07 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201611180227.08145.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 07:27:12 -0000 On Thursday, November 17, 2016 09:12:48 pm Sean Turner wrote: > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 In descending order of preference: 1) TLS 2.0 or TLS 2 2) TLS 1.3 3) TLS 4 There is no versioning here that doesn't have a confusion risk. Some people worry about an SSL/TLS 2.0 confusion. I worry that TLS 1.3 won't be taken with as much seriousness/urgency at a glance by those with a lower technical understanding (too many of us resort to "it's really like TLS 2" when trying to explain the leap). TLS 4 or elventybillion just forces people to answer the "what happened to TLS 3" question forever, without really making anything more clear. The confusion a big number jump tries to avoid is far better addressed by experts finally stopping with the SSL/TLS conflation. If the consensus is to keep the status quo, in spite of major changes that would normally dictate a major version bump, that's unfortunate... but the world will not implode. :/ Dave PS I suspect that a push for a major version bump a year and a half ago would've had more support, but many of us who are currently in favor of it were still in the "meh, whatever" camp. Oh well. From nobody Fri Nov 18 01:19:36 2016 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 2C11912941A for ; Fri, 18 Nov 2016 01:19:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nF6Yqz8amZj2 for ; Fri, 18 Nov 2016 01:19:32 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (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 85F4A12955F for ; Fri, 18 Nov 2016 01:19:32 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id u144so3865297wmu.1 for ; Fri, 18 Nov 2016 01:19:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=yFyEXmmgQo97WEkB7uGMU0vMsVRSDxIlgge0cYwTJbM=; b=K2/CTX2Spq4YyoVA47BP/gPMBFiWtdBOgnINtSm6xp+qdPVBc/MiAXq4x5wa5Lf9A/ iQe6kA24L6fuKNO1l0U6OhVo1zGczQ46Dhn7MJCpeW7OoBr+ZrJ3WNXIwVuF8SF49xEG neRWMebfZMuKucMVALexpEov7Oy+0Ewp9pO/YHK/7usPqFR/FF9TdQ+VroWMq++63WXh p+MnJ2CD1xY1ZMOTeM72OrPov8V1WyV7jsPvwXzFL6AkzL2smCG0QuRlcRpwIWbbd/mo lQf/TC4eqjhI8cT0+dMdWyDcpcnn3Y/EycW89DE6NABOyrjwJI2sHIVUW5Kb4me69iLl X63g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yFyEXmmgQo97WEkB7uGMU0vMsVRSDxIlgge0cYwTJbM=; b=EwmZz7Ch+s8osrIfJx/UsH6dqLH8pp7MBANcXGwphr0US8n7/FVQqBHE3376KQhbuF EqCq+iTUtl3FwuUSwyjnwZ97h8TH/4d/m45RSsBSiuyxxLMEtrB7AaROSvwLDPBftAp4 M8VjvdEHgp6M6snNgsYcDwIqN07/eR6wDHYexUoBwPc0MJEjgHuDlBfRzK+x5F1XiJA0 Z43afaDwvM4XO1QC1O8vNhs93ab61gC9baJSp/dqjTQycaKs2InKGrtduSAdRpA6QUxP ct+fcWBGbdNZ29lB16+b3lEU8TUzP7BPVpHxzPHazl7QZj4kEZKoNfZZpxayW4QemTV2 Hmeg== X-Gm-Message-State: AKaTC03XnVNhc5wdinEjrFfeYhonpf7zkuq1ucbPNYa/N9+wVwsKgod2WP8NQjkD6VBV5s2QHP59aTTHm8ZmQg== X-Received: by 10.194.116.66 with SMTP id ju2mr4854282wjb.223.1479460770792; Fri, 18 Nov 2016 01:19:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.32.1 with HTTP; Fri, 18 Nov 2016 01:19:30 -0800 (PST) From: Kazuho Oku Date: Fri, 18 Nov 2016 18:19:30 +0900 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a1130d266b3cc0405418fcd62 Archived-At: Subject: [TLS] Verifying the second HelloRequest in TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 09:19:34 -0000 --001a1130d266b3cc0405418fcd62 Content-Type: text/plain; charset=UTF-8 Hi, In section 4.1.2, the latest draft (18) states that a ClientHello sent in response to a HelloRetryRequest must be identical to the first one except for addition, modification, and removal of the designated extensions. To be precise, the draft states: In that case, the client MUST send the same ClientHello (without modification) except: - If a "key_share" extension was supplied in the HelloRetryRequest, replacing the list of shares with a list containing a single KeyShareEntry from the indicated group. - Removing the "early_data" extension (Section 4.2.8) if one was present. Early data is not permitted after HelloRetryRequest. - Including a "cookie" extension if one was provided in the HelloRetryRequest. Does this mean that the ClientHello must be at the octet-level be equivalent (with the exception for the positions at which the necessary extensions are inserted)? Or does this mean that a semantically equivalent ClientHello must be accepted? If this is the case, it would mean that a client is allowed to exchange the order of the extensions within ClientHello. There could be other ways to construct an semantically identical ClientHello that looks different at byte level. I think the latest draft can be interpreted in either way (please correct me if I am wrong), and would like to learn what the answer would be. Thank you in advance. -- Kazuho Oku --001a1130d266b3cc0405418fcd62 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

In section 4.1.2, the latest draft (18) states = that a ClientHello sent in response to a HelloRetryRequest must be identica= l to the first one except for addition, modification, and removal of the de= signated extensions.

To be precise, the draft states:

= =C2=A0 =C2=A0In that case, the client MUST send the same
=C2=A0 =C2=A0Cl= ientHello (without modification) except:

=C2=A0 =C2=A0- =C2=A0If a &= quot;key_share" extension was supplied in the HelloRetryRequest,
= =C2=A0 =C2=A0 =C2=A0 replacing the list of shares with a list containing a = single
=C2=A0 =C2=A0 =C2=A0 KeyShareEntry from the indicated group.
<= br>=C2=A0 =C2=A0- =C2=A0Removing the "early_data" extension (Sect= ion 4.2.8) if one was
=C2=A0 =C2=A0 =C2=A0 present.=C2=A0 Early data is = not permitted after HelloRetryRequest.

=C2=A0 =C2=A0- =C2=A0Includin= g a "cookie" extension if one was provided in the
=C2=A0 =C2= =A0 =C2=A0 HelloRetryRequest.

Does this mean that the ClientHello mu= st be at the octet-level be equivalent (with the exception for the position= s at which the necessary extensions are inserted)?

Or does this mean= that a semantically equivalent ClientHello must be accepted? If this is th= e case, it would mean that a client is allowed to exchange the order of the= extensions within ClientHello. There could be other ways to construct an s= emantically identical ClientHello that looks different at byte level.
I think the latest draft can be interpreted in either way (please correct= me if I am wrong), and would like to learn what the answer would be.
Thank you in advance.

--
Kazuho Oku
--001a1130d266b3cc0405418fcd62-- From nobody Fri Nov 18 01:42:49 2016 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 4A03812966B for ; Fri, 18 Nov 2016 01:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YEB4y2-k9XFS for ; Fri, 18 Nov 2016 01:42:45 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 A03A912963C for ; Fri, 18 Nov 2016 01:42:45 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id x190so255382502qkb.0 for ; Fri, 18 Nov 2016 01:42:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QleZaR533rnx/sS5iq/g57EJvxL1Rxz066NZQWeiVKc=; b=IDqK7s5ganaI/qjzsFUS4ZGi9k+3IpHQrZRvFFAEE3DNnLvAki6/6lY/AUuT38PMrn uSqXHEW21HX6RUkiI422Z0HHEcwn64SZuIInZ9eDQG4vV3MgStbgcegp/tPaqfc6Vvrk KVdEeOdiPfnk0NqTbXk7toiRjGpSK4E8D1IEN7ctPXFnwJdBO/L/YOn5ZJZ9WTUepQHX tKO7xmSEQ5PPfW+wqz2iAY8rz9wro0dHarX5NvjrE4W+/tAmgovgX3wKLOV+xuyfJlzF 6aiNe+KyhV21v7IeUXk0TkWnimAs8AHD4K6zLSEnCM9No7Vr/QMMwsRwwpVttMVxrA7j 10QQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QleZaR533rnx/sS5iq/g57EJvxL1Rxz066NZQWeiVKc=; b=aDvJRT378DYT6FVVg4TNZPURBR0D0JvYCFbnNDmXWxD4TR8IG1CF0Ha7n6jq6HdNFN 1vYhDbqRVqPOq4MXfao7VsY5NK+gRysCcubtSKLF7eYiUehwhjzoHP0wyR7viAv1pUhG MMH4Vnzo6tHIuy11TYGJXc7O4a+tAxtzshXSWY1hBt35vPGTLMN/Y5in68Se/duQxSlg EhsTK5iy7RtaR+dO6te8HjAViyUmBxFmG3W4aAfXB0OpWyf30zEkUmbKy5ZHk7p7esDi cjtb07moPKeGiOlJ7/OkF0ZDGm3/PYY4k8j423tkFhTYwZ2i9i531OFGHtHMxq6qA/Li GJZA== X-Gm-Message-State: AKaTC00XQd/4UAW/PHYyM4+4xeeZyWCW8rfZD6WQV8isNbPz3m3xSPEmS5YSd6QRiXHUMabSGRwj9QuLXme7ZA== X-Received: by 10.55.184.68 with SMTP id i65mr9830674qkf.5.1479462164780; Fri, 18 Nov 2016 01:42:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Fri, 18 Nov 2016 01:42:44 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Fri, 18 Nov 2016 18:42:44 +0900 Message-ID: To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 09:42:47 -0000 On 18 November 2016 at 11:12, Sean Turner wrote: > - Leave it TLS 1.3 There is no point in re-litigating this decision. The consensus call was pretty clear in the room. Perhaps the question would have been better phrased as: "does anyone have new information that would suggest those present at the meeting made the wrong choice?" or "does anyone vehemently object to this decision?" I see no new information in the responses thus far. On 18 November 2016 at 16:27, Dave Garrett wrote: > I suspect that a push for a major version bump a year and a half ago would've had more support Yep, that would have been a more appropriate time to raise the naming thing. Now lots of people know this thing as TLS 1.3, which means a name change would be a big setback to our marketing efforts (such as they are ;)... From nobody Fri Nov 18 02:10:01 2016 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 C1CA01294F7 for ; Fri, 18 Nov 2016 02:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 dAgweUdoVGTh for ; Fri, 18 Nov 2016 02:09:56 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31FC8129426 for ; Fri, 18 Nov 2016 02:09:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1479463796; x=1510999796; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DBBCqX4GPeDq+dIkBtr7zqIk5lqrSz7Vb95xHw2UN+A=; b=fce0Db2drh3X779MiH1jNlIKiQ1L3xepqNsrAcXqTpdXaFQfQo91AEoy 2EpPJDYth1hOo3qYA88KpwuR4k+6mm8D4Fs/5i6t6yRghtNzEO9ADdatr HVwSoEw4BvBVEl+hkPzV9ANh1Hw5f8sup5BJr387Ww9O+C5XlTC1G9j6e rjTKSPVVzMQGq2GecguM/yfDwcmABlEfxMkX6z57xqEsT2mlKjGzd3Agf JFPOVEOYRvKWDcG/Mx3imdXNMCjHg6xbvtNPGrvD+LHdoJsBwi4CgZOzV XoS0gerkfXy2NP+U2EOPNDNz0PQp7L8kFxn961PYvEOw4hMjdjiYJAHaB w==; X-IronPort-AV: E=Sophos;i="5.31,656,1473076800"; d="scan'208";a="115816624" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 18 Nov 2016 23:09:52 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.25) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 18 Nov 2016 23:09:52 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 18 Nov 2016 23:09:52 +1300 From: Peter Gutmann To: Sean Turner , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFcD667DaatoU6RNleDGo1T66DehSt+ Date: Fri, 18 Nov 2016 10:09:52 +0000 Message-ID: <1479463783973.10653@cs.auckland.ac.nz> References: In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 10:10:00 -0000 Sean Turner writes:=0A= =0A= >The consensus in the room was to leave it as is, i.e., TLS1.3, and to not= =0A= >rebrand it to TLS 2.0, TLS 2, or TLS 4.=0A= =0A= Which is kind of odd, because the consensus on the list when it was debated= =0A= here a while back was to not call it 1.3. It definitely shouldn't be 1.3= =0A= because it's a new protocol, nothing like the 1.0 - 1.2 that preceded it.= =0A= Since the general opinion (on the list) so far seems to be to call it TLS 4= ,=0A= I'd be quite happy to go with that.=0A= =0A= Peter.= From nobody Fri Nov 18 03:53:25 2016 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 E340C1294F3 for ; Fri, 18 Nov 2016 03:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 D1O9QxkqMSlA for ; Fri, 18 Nov 2016 03:53:22 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD81F1294D4 for ; Fri, 18 Nov 2016 03:53:22 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 7D6A5284B6F; Fri, 18 Nov 2016 11:53:21 +0000 (UTC) Date: Fri, 18 Nov 2016 11:53:21 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20161118115321.GR26244@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org 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, 18 Nov 2016 11:53:24 -0000 On Fri, Nov 18, 2016 at 06:42:44PM +0900, Martin Thomson wrote: > There is no point in re-litigating this decision. The consensus call > was pretty clear in the room. My impression was that the list is where rough consensus is established, and consensus in "the room" does not preempt discussion on the list. Rather "the room" merely provides an early indication of the likely consensus position. -- Viktor. From nobody Fri Nov 18 04:19:19 2016 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 4D3C7129481 for ; Fri, 18 Nov 2016 04:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 OnWsFztCYLsX for ; Fri, 18 Nov 2016 04:19:16 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 203EB127A90 for ; Fri, 18 Nov 2016 04:19:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 1571B12992; Fri, 18 Nov 2016 14:19:15 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id rGjec94IxhDr; Fri, 18 Nov 2016 14:19:14 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id BE7B221C; Fri, 18 Nov 2016 14:19:14 +0200 (EET) Date: Fri, 18 Nov 2016 14:19:10 +0200 From: Ilari Liusvaara To: Sean Turner Message-ID: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 12:19:18 -0000 On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG > should rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and > to not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm > this decision on the list so please let the list know your top > choice between: I say leave it. I would leave that sort of version changes to really major shifts where the compatiblity is completely broken. And TLS 1.3 is not that major change. -Ilari From nobody Fri Nov 18 04:48:52 2016 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 83E2A12969F for ; Fri, 18 Nov 2016 04:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 fgULBxGvnVbZ for ; Fri, 18 Nov 2016 04:48:50 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 75E8112969A for ; Fri, 18 Nov 2016 04:48:50 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D8A0A433480; Fri, 18 Nov 2016 12:48:49 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id C181243340F; Fri, 18 Nov 2016 12:48:49 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479473329; bh=SqxZHdbRTUb9ScspPWgkfrTt4CsbXG02ortQ7rfKIf4=; l=664; h=From:To:Date:References:In-Reply-To:From; b=vp6jobSFANjnzzgXexK3YO4mz+Uh0vGikdcevtic3von03RZ6prcHmojWBh/m+jA0 HM73NXw4u4MLZ30MfDoFx58qDomjERq0wsKg+0XD34RrVfRN1zkJE9IbDMVD8fN0kZ tr3o0825HtqDYc6NmmYFJMSYgIdlbxM+2mqxOEgY= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BDF7D1FC8B; Fri, 18 Nov 2016 12:48:49 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 18 Nov 2016 04:48:49 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 18 Nov 2016 07:48:49 -0500 From: "Salz, Rich" To: Peter Gutmann , Sean Turner , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDe2RwA///XTGA= Date: Fri, 18 Nov 2016 12:48:49 +0000 Message-ID: <6d9df662c09d441b9b37fcc0b566cb64@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1479463783973.10653@cs.auckland.ac.nz> In-Reply-To: <1479463783973.10653@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.81] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 12:48:51 -0000 Renaming was brought up on the list before like Peter said. It was discuss= ed with at least one chair during an interim, and I was told we'll bring it= up when we're almost done because we don't want to distract the group now.= And I'll attribute Martin's atypical heavy-handed comments to typical pos= t-IETF exhaustion on his part. Especially with the flurry of activity over the past couple of weeks, this = is not the TLS 1.x we all know. We should change the version number, and f= or the sake of comity I don't care what it is. -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz From nobody Fri Nov 18 05:04:02 2016 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 89F3D1296DA for ; Fri, 18 Nov 2016 05:04:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 prVQSxTkTUOh for ; Fri, 18 Nov 2016 05:03:55 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033A0129485 for ; Fri, 18 Nov 2016 05:03:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1479474235; x=1511010235; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BI2k1bdcQKMWCeNcyrZDvFjAU8y9MvJ/y3s6d0a6bt8=; b=o042ho0lYg2srKllc28P/1KOUAF9rf5WPwRuQPcFSPrzqP+u6Cj9Maz6 B9x+D8B0sVpfzYWgys1siNhAWbgjQj03GWG8jxznY1USPyUfZAAu7cVBR MA3xEZOTQNUcrzxH9DAcfi7+xNARt7OkzZtCH2pCClzNO9KVDk66QyY7l 5Ke17QBzi/GfcHBE0wq9mseOeP4CvpiAZRUfYByXaILvs4a/cd1QeblX4 Gk4nqu11bTx0ef0Ks5/rO6fSVgHQrQwV/w2l2X4JpebFh4C1CDtkU4tri XHDzd1lc3e3jTXAmURrkO2cf0mtDRAEElGrqW+1H0NfNQgYeKB76qhVTa Q==; X-IronPort-AV: E=Sophos;i="5.31,509,1473076800"; d="scan'208";a="115828256" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from uxcn13-tdc-a.uoa.auckland.ac.nz ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Nov 2016 02:03:50 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 19 Nov 2016 02:03:50 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 19 Nov 2016 02:03:50 +1300 From: Peter Gutmann To: Ilari Liusvaara , Sean Turner Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFcD667DaatoU6RNleDGo1T66Ddz30AgADmRXM= Date: Fri, 18 Nov 2016 13:03:50 +0000 Message-ID: <1479474222033.25911@cs.auckland.ac.nz> References: , <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 13:04:01 -0000 Ilari Liusvaara writes:=0A= =0A= >I would leave that sort of version changes to really major shifts where th= e=0A= >compatiblity is completely broken. And TLS 1.3 is not that major change.= =0A= =0A= So you're saying that apart from the different algorithms, cipher suites,= =0A= messages, message fields, message flow, handshaking, negotiation, extension= s,=0A= and crypto, it's practically the same thing?=0A= =0A= Peter.=0A= From nobody Fri Nov 18 07:35:39 2016 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 C1E5712958D for ; Fri, 18 Nov 2016 07:35:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.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 bfQ1eU3hUx6N for ; Fri, 18 Nov 2016 07:35:36 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E238128B37 for ; Fri, 18 Nov 2016 07:35:35 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id EBD7A4E0C4 for ; Fri, 18 Nov 2016 10:35:33 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=J//7Dfl9wLvlhU9vdDOSwnnWRdM=; b=HZA+co An7lwj+vR6W/KU+k05APO4tydIDl5GxYtk06YDf9MqcveHGsDIDCyIMSfYcLtX8H MQXYV5/cpzp/8ostK5++8bkDEwUqhFf2zMGB1nK0Ne0bUSCwDvegqWClkS6YUGIE +A/14T7yIlPiIyWq+ZgOACxmnKVXeg3yValeE= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id E41DF4E0C3 for ; Fri, 18 Nov 2016 10:35:33 -0500 (EST) Received: from mail-qk0-f178.google.com (unknown [209.85.220.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 8D6ED4E0C2 for ; Fri, 18 Nov 2016 10:35:33 -0500 (EST) Received: by mail-qk0-f178.google.com with SMTP id n204so267849271qke.2 for ; Fri, 18 Nov 2016 07:35:33 -0800 (PST) X-Gm-Message-State: AKaTC00g7AJo/4Dc6I88xPyJbhj5FwItKudJFYiCBAQmBwIfBnwKRiJGZUtRHrlTjAjViscCzxGPZAecU7lg8g== X-Received: by 10.55.19.97 with SMTP id d94mr418707qkh.200.1479483332758; Fri, 18 Nov 2016 07:35:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.44.205 with HTTP; Fri, 18 Nov 2016 07:34:52 -0800 (PST) In-Reply-To: References: From: Eric Mill Date: Fri, 18 Nov 2016 10:34:52 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=001a114009c08015f20541950eb8 X-Pobox-Relay-ID: A500F5C0-ADA4-11E6-B61D-3AB77A1B28F4-82875391!pb-smtp2.pobox.com Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 15:35:38 -0000 --001a114009c08015f20541950eb8 Content-Type: text/plain; charset=UTF-8 On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides-97-tls- > rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > Because I have literally had the experience of a (very) major organization insisting that HTTPS was not secure because the "most recent" version, SSL version 3.0, had recently been broken, I support moving this out to TLS 4. But more generally, I support getting off of the major/minor version naming scheme. There are no "minor versions" of TLS. Every one is a huge deal for the ecosystem to update to. I think it will be simpler for everyone in the future if TLS always just uses whole numbers with no decimal points. So either TLS 4 or TLS 2 would be improvements in some way. TLS 2.0 wouldn't get you improvements in either category. As really a non-participant in the WG, I don't expect my preference to count much, but for whatever it's worth, it would be: TLS 4 > TLS 2 > TLS 1.3 > TLS 2.0 -- Eric by 2 December 2016. > > Thanks, > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- konklone.com | @konklone --001a114009c08015f20541950eb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= hu, Nov 17, 2016 at 9:12 PM, Sean Turner <sean@sn3rd.com> wrote= :
At IETF 97, the chairs lead a discussio= n to resolve whether the WG should rebrand TLS1.3 to something else.=C2=A0 = Slides can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tls-re= branding-aka-pr612-01.pdf.

The consensus in the room was to leave it as is, i.e., TLS1.3, and to not r= ebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this decisi= on on the list so please let the list know your top choice between:

- Leave it TLS 1.3
- Rebrand TLS 2.0
- Rebrand TLS 2
- Rebrand TLS 4

Because I have literall= y had the experience of a (very) major organization insisting that HTTPS wa= s not secure because the "most recent" version, SSL version 3.0, = had recently been broken, I support moving this out to TLS 4.
But more generally, I support getting off of the major/minor ve= rsion naming scheme. There are no "minor versions" of TLS. Every = one is a huge deal for the ecosystem to update to. I think it will be simpl= er for everyone in the future if TLS always just uses whole numbers with no= decimal points.

So either TLS 4 or TLS 2 would be= improvements in some way. TLS 2.0 wouldn't get you improvements in eit= her category.

As really a non-participant in the W= G, I don't expect my preference to count much, but for whatever it'= s worth, it would be:

TLS 4 > TLS 2 > TLS 1.= 3 > TLS 2.0
=C2=A0
-- Eric

by 2 December 2016.

Thanks,
J&S
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--
--001a114009c08015f20541950eb8-- From nobody Fri Nov 18 07:40:52 2016 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 4351C1295F4 for ; Fri, 18 Nov 2016 07:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 Ooe00EHEevc8 for ; Fri, 18 Nov 2016 07:40:49 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 4503312958D for ; Fri, 18 Nov 2016 07:40:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 5E23212265; Fri, 18 Nov 2016 17:40:48 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id y-5k_P44vVQA; Fri, 18 Nov 2016 17:40:48 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 1A6582310; Fri, 18 Nov 2016 17:40:48 +0200 (EET) Date: Fri, 18 Nov 2016 17:40:43 +0200 From: Ilari Liusvaara To: Peter Gutmann Message-ID: <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1479474222033.25911@cs.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 15:40:51 -0000 On Fri, Nov 18, 2016 at 01:03:50PM +0000, Peter Gutmann wrote: > Ilari Liusvaara writes: > > >I would leave that sort of version changes to really major shifts where the > >compatiblity is completely broken. And TLS 1.3 is not that major change. > > So you're saying that apart from the different algorithms, cipher suites, > messages, message fields, message flow, handshaking, negotiation, extensions, > and crypto, it's practically the same thing? Yes. One can downnegotiate TLS 1.3 to TLS 1.2. -Ilari From nobody Fri Nov 18 07:42:20 2016 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 7E0A41295F4 for ; Fri, 18 Nov 2016 07:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ouVkKPrvUnTn for ; Fri, 18 Nov 2016 07:42:17 -0800 (PST) Received: from srv1.stroeder.com (srv1.stroeder.com [213.240.180.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D9BE12958D for ; Fri, 18 Nov 2016 07:42:17 -0800 (PST) Received: from srv4.stroeder.local (unknown [10.1.1.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.stroeder.local", Issuer "stroeder.com Server CA no. 2009-07" (not verified)) by srv1.stroeder.com (Postfix) with ESMTPS id 7E1354DF; Fri, 18 Nov 2016 16:42:15 +0100 (CET) Received: from gt1.stroeder.com (localhost [127.0.0.1]) by srv4.stroeder.local (Postfix) with ESMTP id DBB403C8; Fri, 18 Nov 2016 16:42:14 +0100 (CET) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Fri, 18 Nov 2016 16:42:14 +0100 From: =?UTF-8?Q?Michael_Str=C3=B6der?= To: Eric Mill In-Reply-To: References: Message-ID: <4c007b23b4aecb4f9f53f4a94d90ac14@stroeder.com> X-Sender: michael@stroeder.com User-Agent: Roundcube Webmail/1.2.2 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 15:42:19 -0000 On 2016-11-18 16:34, Eric Mill wrote: > As really a non-participant in the WG, I don't expect my preference to > count much, dito for in my case > but for whatever it's worth, it would be: > > TLS 4 > TLS 2 > TLS 1.3 > TLS 2.0 +1 Ciao, Michael. From nobody Fri Nov 18 07:49:08 2016 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 95D7E129518 for ; Fri, 18 Nov 2016 07:49:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 GMxBLnQgIshk for ; Fri, 18 Nov 2016 07:49:05 -0800 (PST) Received: from resqmta-po-02v.sys.comcast.net (resqmta-po-02v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:161]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DDAF129620 for ; Fri, 18 Nov 2016 07:49:05 -0800 (PST) Received: from resomta-ch2-14v.sys.comcast.net ([96.114.154.238]) by resqmta-po-02v.sys.comcast.net with SMTP id 7lOucRCXq1zBd7lPUctjSv; Fri, 18 Nov 2016 15:49:04 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1479484144; bh=jkTfGWD+jDBRyc8Ut4Kvdo2IzHB8dGJDkXV9aLF7wLg=; h=Received:Received:Content-Type:Mime-Version:Subject:From:Date: Message-Id:To; b=M4W6CfmbW1arzkcS5Zn0pDPbmSCfmewMhfOq50p9xyvQDGGO+b14Pj64lXDroIA+s cozob10CgKvrMh1OlHOdPDPrx85T62w7un3qE2fRSS6XJfCASea+Zm/aPCjEWFO1j/ v/uoWWU35JJmDnzwpdTB/svtARrK82RjH4iBn53k6NPm1cTxLd553roguXJBfnTWdJ HMQEqNDH2ExcUYIFMKa82gD7bVR/4KPVVL5eiWJqTUIxT5e0+zA5TgE4l5ZcE5jdVt +Jc4T2GkDoukpaOR3i2167M+YEMCgc8dROF3Yo22+QDm+iXWO6marvgmIxhIUpE9mm RB7d8dvM/ekIg== Received: from [192.168.29.225] ([50.170.36.213]) by resomta-po-14v.sys.comcast.net with SMTP id 7lPTcXKdgLdMy7lPUcilmb; Fri, 18 Nov 2016 15:49:04 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Will Serumgard X-Mailer: iPhone Mail (14B100) In-Reply-To: <4c007b23b4aecb4f9f53f4a94d90ac14@stroeder.com> Date: Fri, 18 Nov 2016 07:49:03 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4c007b23b4aecb4f9f53f4a94d90ac14@stroeder.com> To: =?utf-8?Q?Michael_Str=C3=B6der?= X-CMAE-Envelope: MS4wfBXvPmGCUDwQYUTPiGb/SIjMUxx+x+E9FAOCdDb40ExuFrzcAc/Bithw492bmncnGqcoUZ4hGfjeDJwqsEDf/qyDQuqV0dwe7ltWKl0fJ2f4A/DETdX3 r3OJogv2EGCy13Ubn2UjDunBb28ViUFZ/XQ7AG0hQqHRynQsAEvh74qnccNy2EIJeaLfkqoFGMZuStPNciJOI5FJ8RBUAsrdkJUg+EzlJ+WyKjBl4YfN74N8 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 15:49:06 -0000 At this point it is a little late to change. I say stay with TLS1.3. As some= others pointed out maybe we can make a jump in the next version.=20 Will Serumgard > On Nov 18, 2016, at 7:42 AM, Michael Str=C3=B6der w= rote: >=20 >> On 2016-11-18 16:34, Eric Mill wrote: >> As really a non-participant in the WG, I don't expect my preference to >> count much, >=20 > dito for in my case >=20 >> but for whatever it's worth, it would be: >> TLS 4 > TLS 2 > TLS 1.3 > TLS 2.0 >=20 > +1 >=20 > Ciao, Michael. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Nov 18 07:56:40 2016 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 582301295CA for ; Fri, 18 Nov 2016 07:56:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4J35L8zRQnlv for ; Fri, 18 Nov 2016 07:56:37 -0800 (PST) Received: from mail-it0-x22f.google.com (mail-it0-x22f.google.com [IPv6:2607:f8b0:4001:c0b::22f]) (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 072A3127071 for ; Fri, 18 Nov 2016 07:56:37 -0800 (PST) Received: by mail-it0-x22f.google.com with SMTP id l8so32571425iti.1 for ; Fri, 18 Nov 2016 07:56:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=AtFGsHfMWYwKnqMneNKDsxqR4XT5As4JnnLlsw1+hSM=; b=sAnaRHLDqY7wV5+7EpA8KFP2+ML2vFEK57851biasfhuy/dARCgxTN0DD5YsXT5pll CFhyNtxXgGwFTgsTN57Dl0KhkswzSUPnHpK7oYOTeRmFUVEv7q/LHiZmkapSPQqCUl2a FOhJ/93TNdYCMnCk3mCrmKHC/qyA8KthIG2IYO7OGYyA6ZFMkKzJoOECmK2+wB1Yisw4 zOdQzd7qn7mqoB/7gBPImd3vKywGzq19uBWtDXZ7v1YfcbtR4n2TOU1K/R5wGsn76LU3 ziZ4mi2gNSpuWfaaqM86s7nBP13XWFG5fU/Nh0E4UyS0CG/ke0C54b7u/2wUSvFlzlsa u2MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=AtFGsHfMWYwKnqMneNKDsxqR4XT5As4JnnLlsw1+hSM=; b=YT0ggP9U/xfwYT2Df3HBLLmDLucrDVxVwSl2o1Dx0AvBurmBJkqe4mQGwJwt+aerTc YXdrOGZ05feaKNbAVkzgbgPOVHq7XSYvse1jkFxFH30xDGLqMsStIpCvxQmNXofOq3gB FfevdPD2TafA/pJlRap8cCbYiELUheKBqNhXIYxsVuF9Q5AqzR/QFA5GeiBFdXU1Te4h 7IOvCKqXt5pUDQwifkRc7PYRew40Q5hXCN2IjnhpkmYVhY0rrRdfsKzeWRtGFgUsoXvX 7FdJE7XeeWn2hMerkdq2CEqgZXl95tl1nUWZaJ6S14bM3xxMFaOP+noBUvPpsuXUdOKh 8QpA== X-Gm-Message-State: AKaTC02pCks5X+5MiNzCVfUN0z6iI7ZM5apu8Rj28gjNviAKCncy7ug0OLH9sReQiopqDlCM011HW+bGLLJ98w== X-Received: by 10.36.163.8 with SMTP id p8mr421975ite.92.1479484596353; Fri, 18 Nov 2016 07:56:36 -0800 (PST) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.36.104.134 with HTTP; Fri, 18 Nov 2016 07:56:35 -0800 (PST) In-Reply-To: References: <4c007b23b4aecb4f9f53f4a94d90ac14@stroeder.com> From: Adam Langley Date: Fri, 18 Nov 2016 07:56:35 -0800 X-Google-Sender-Auth: TNkwg6ytRGWUonNKXst2lNG-fMw Message-ID: To: Will Serumgard Content-Type: multipart/alternative; boundary=94eb2c117e04d10254054195594b Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 15:56:38 -0000 --94eb2c117e04d10254054195594b Content-Type: text/plain; charset=UTF-8 On Fri, Nov 18, 2016 at 7:49 AM, Will Serumgard wrote: > At this point it is a little late to change. I say stay with TLS1.3. As > some others pointed out maybe we can make a jump in the next version. > Renumbering SSL 3.1 as TLS 1.0 was a mistake in the first place, but I don't believe that changing the version of TLS 1.3 (even if monotonic) will help at this point. Thus I support keeping TLS 1.3. Cheers AGL --94eb2c117e04d10254054195594b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 18, 2016 at 7:49 AM, Will Serumgard <serumgard@comcast.net> wrote:
At this point it is = a little late to change. I say stay with TLS1.3. As some others pointed out= maybe we can make a jump in the next version.

Renumbering SSL 3.1 as TLS 1.0 was a mistake in the first place, bu= t I don't believe that changing the version of TLS 1.3 (even if monoton= ic) will help at this point. Thus I support keeping TLS 1.3.

=

Cheers

AGL
--94eb2c117e04d10254054195594b-- From nobody Fri Nov 18 07:56:58 2016 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 CDE04127071 for ; Fri, 18 Nov 2016 07:56:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no 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 a-q7Sdq6iBVb for ; Fri, 18 Nov 2016 07:56:55 -0800 (PST) Received: from vsp5.ballou.se (vsp5.ballou.se [91.189.40.84]) by ietfa.amsl.com (Postfix) with SMTP id 2E43F12963F for ; Fri, 18 Nov 2016 07:56:54 -0800 (PST) X-Halon-Scanned: 7f4a955dd6f4c149d51110a345668da22aa82d04 Received: from nmail1.ballou.se (unknown [10.0.0.116]) by vsp5.ballou.se (Halon) with ESMTP id 9e803bf1-ada7-11e6-ab79-0050568f70bb; Fri, 18 Nov 2016 16:56:51 +0100 (CET) Received: from [192.168.0.178] (c-efcce555.06-134-73746f39.cust.bredbandsbolaget.se [85.229.204.239]) (Authenticated sender: henrick@streamsec.se) by nmail1.ballou.se (Postfix) with ESMTPSA id 21E8FC9570 for ; Fri, 18 Nov 2016 16:56:51 +0100 (CET) References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz> <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> To: tls@ietf.org From: =?UTF-8?Q?Henrick_Hellstr=c3=b6m?= Message-ID: Date: Fri, 18 Nov 2016 16:56:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: henrick@streamsec.se 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, 18 Nov 2016 15:56:57 -0000 On 2016-11-18 16:40, Ilari Liusvaara wrote: > On Fri, Nov 18, 2016 at 01:03:50PM +0000, Peter Gutmann wrote: >> So you're saying that apart from the different algorithms, cipher suites, >> messages, message fields, message flow, handshaking, negotiation, extensions, >> and crypto, it's practically the same thing? > > Yes. One can downnegotiate TLS 1.3 to TLS 1.2. Shouldn't you be able to do that between major protocol versions as well? From nobody Fri Nov 18 08:16:46 2016 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 BB971127071 for ; Fri, 18 Nov 2016 08:16:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.419 X-Spam-Level: X-Spam-Status: No, score=-8.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 QrofD8iS5m9O for ; Fri, 18 Nov 2016 08:16:43 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DDB126B6D for ; Fri, 18 Nov 2016 08:16:43 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2171B7FD47; Fri, 18 Nov 2016 16:16:43 +0000 (UTC) Received: from pintsize.usersys.redhat.com (vpn1-6-190.ams2.redhat.com [10.36.6.190]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAIGGfMa020968 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 18 Nov 2016 11:16:42 -0500 From: Hubert Kario To: tls@ietf.org Date: Fri, 18 Nov 2016 17:16:36 +0100 Message-ID: <1727072.YfzU8VvnnN@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.6-201.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1680258.9a9QuEyxGQ"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Fri, 18 Nov 2016 16:16:43 +0000 (UTC) Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 16:16:46 -0000 --nextPart1680258.9a9QuEyxGQ Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Friday, 18 November 2016 11:12:48 CET Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-p= r6 > 12-01.pdf. >=20 > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: >=20 > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 Keep it at TLS 1.3. TLS 2.0 and 2 are just too likely to be confused with SSL 2. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1680258.9a9QuEyxGQ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYLylkAAoJEJKo0bgB0vX10fQQAIz7qfzeKeS6TwfYchLRrlMi P1mb1YbP+Qibz/JseDRbxwtyxk/6CQ1eK0Pzwudw2+O4Ne4jAK4UvYoZ9tZ/e/cQ bxKzOYpzQhoCY2zZ2dzwYeGNJaJGhIpNTM4gEXfvrOBOzHt+hQNDlbSqhm5AjzSX 6OU/tdauCDTwhghCZF7uMMS3UuFk1HTd7eirgtFSjgqKhQelZKbyG5rgwUPGmYxB 29TDFZfQFFqh99cVswUuU00B0WTDQzKhVRlcwkiOxpM2uku2GawYKGWlYEY8/vxJ oOn+UyK5Zug7OHlN/cyR28PrmXwZhsdaVR3KatAz8/w6YID7yriTndgkekFBVhAv UZpS6NbDhQ5gGqt9BWMAzY2mnY3si2FMTmkvFahpjmzNBffW/zMqJEyIq1Nr2XhW X2eqZY0C4oeCb72+h655ztZefIh8Bt679IXXjoig44DGHzFq51589VHkToiJutLU 4NmP056vRLejMmm3+8e+mmHh/K+AhOsBudWM9WX4/CThx8DiLKdY5cQbbssYtMwb VT4XpTMFVN89UOhirYUxXOGOSR0ZPQiRGhZyWAdnixUrRrzaYI4iOW/WBSGHPE0K 7LZWII0o9ujKqMXbSsz8D/2CkNuufGSnaMtruuUgTblUY9xsFTwjp32P+b/n/px4 eQsYzZy7AapI1yfITM06 =fqjN -----END PGP SIGNATURE----- --nextPart1680258.9a9QuEyxGQ-- From nobody Fri Nov 18 08:47:26 2016 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 D51891295B8 for ; Fri, 18 Nov 2016 08:47:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gnbsIRzS-ix for ; Fri, 18 Nov 2016 08:47:23 -0800 (PST) Received: from mail-it0-x230.google.com (mail-it0-x230.google.com [IPv6:2607:f8b0:4001:c0b::230]) (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 0965612957F for ; Fri, 18 Nov 2016 08:47:23 -0800 (PST) Received: by mail-it0-x230.google.com with SMTP id y23so41132486itc.0 for ; Fri, 18 Nov 2016 08:47:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4DNwgzmfIYn/SbArhMp4Ce4Yzkn9PnXcsWJh/qnRgMI=; b=hjg4GUtjf+rduYsLQ5nHg3FAlaxRaX0nW8qQ/F/+Zr2TyvEoqM6z9E4nvcd9QTWFE9 oubhwKr/Ki8gCVXNHaLguVWWFWMs1mNSv76PUGWfegS2UUDnPs+ch8hR+/P3Orie3QGD UIWab7FUSQBoJqrscXL0Fuyqy+rbiGxUz9ab5lIIcPfWjQDGd+JL5BkqkOpKDfeR8LeW aTYwyeynEh1URFE0+nTCNgGdWR9crosQwR5tHAsoPJxvCwoxfdrOvdfGQznPk6L0lf3l 6/GDo64orrW6aNVWxVZhAlHKnmJndo/3UklLtbSLdaKBl+/1qkMeXfzMCgTly18oUZ39 pGlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4DNwgzmfIYn/SbArhMp4Ce4Yzkn9PnXcsWJh/qnRgMI=; b=EHDr2CylU5ouHnxGWhsTVAhG/JC4/bwGMTsrxWR/jCyLPus0Y3yLeeCPh0JeKGhiuQ gw8RkyCyMCv5+hHQy+fS+O2hWFs/XxEnZDtiWUz6r8aL+mM2ny2wiJyfkjbc/Sv7wjSg Jt9Fla4UHWVZkr704KBRIuXBIhUc6CcsC4owSy7BCAP2vEep1B52xvxhjTlWnzD460/t 5MLE7CPQkYEtkq4RpWT6kaU0lozOMpRZM5JJnUer4oDY/eDjYlreyVjc8kP3QRlNhrm8 1WjqK5P8XAzkrgMaFzuGv2oOnWxX9Gz9OmTu5A/2QNYTcxe3LRB3+zwlYRNpaD3DvI/Z 5ylw== X-Gm-Message-State: AKaTC03BDvWEorYnm67vq5rB4rCYQwknlGqXnsE2gI48WCwWuVp4l8aWTLqQG+E3aWtQZjaeH6+woj2LjKFABg== X-Received: by 10.36.37.199 with SMTP id g190mr616168itg.66.1479487642361; Fri, 18 Nov 2016 08:47:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.8.101 with HTTP; Fri, 18 Nov 2016 08:47:01 -0800 (PST) In-Reply-To: <1727072.YfzU8VvnnN@pintsize.usersys.redhat.com> References: <1727072.YfzU8VvnnN@pintsize.usersys.redhat.com> From: Ira McDonald Date: Fri, 18 Nov 2016 11:47:01 -0500 Message-ID: To: Hubert Kario Content-Type: multipart/alternative; boundary=001a11450caa5f6ada0541960fc8 Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 16:47:25 -0000 --001a11450caa5f6ada0541960fc8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, +1 --- keep TLS 1.3 Cheers, - Ira On Fri, Nov 18, 2016 at 11:16 AM, Hubert Kario wrote: > On Friday, 18 November 2016 11:12:48 CET Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG shou= ld > > rebrand TLS1.3 to something else. Slides can be found @ > > https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-rebranding-aka-pr6 > > 12-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to n= ot > > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decisi= on > > on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > Keep it at TLS 1.3. > > TLS 2.0 and 2 are just too likely to be confused with SSL 2. > > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11450caa5f6ada0541960fc8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

+1 --- keep TLS 1.3<= br>
Cheers,
- Ira

On Fri, Nov 18, 2016 at 11:16 AM, Hubert Kar= io <hkario@redhat.com> wrote:
On Friday, 18 November 2016 11:12:48 CET Sean Turner w= rote:
> At IETF 97, the chairs lead a discussion to resolve whether the WG sho= uld
> rebrand TLS1.3 to something else.=C2=A0 Slides can be found @
> https://www.ietf.org= /proceedings/97/slides/slides-97-tls-rebranding-aka-pr6
> 12-01.pdf.
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not
> rebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this = decision
> on the list so please let the list know your top choice between:
>
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4

Keep it at TLS 1.3.

TLS 2.0 and 2 are just too likely to be confused with SSL 2.

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a11450caa5f6ada0541960fc8-- From nobody Fri Nov 18 09:31:39 2016 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 046491295D0 for ; Fri, 18 Nov 2016 09:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 gA9L82yd4bFQ for ; Fri, 18 Nov 2016 09:31:36 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC248129443 for ; Fri, 18 Nov 2016 09:31:35 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1c7n0e-0004kz-Gj for tls@ietf.org; Fri, 18 Nov 2016 18:31:34 +0100 Received: from [10.5.2.14] (helo=xmail04.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1c7mzq-00046g-2Y for tls@ietf.org; Fri, 18 Nov 2016 12:31:30 -0500 Received: (qmail 25669 invoked from network); 18 Nov 2016 17:30:39 -0000 Received: from unknown (HELO [26.137.103.170]) (Authenticated-user:_huitema@huitema.net@[172.56.44.138]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 18 Nov 2016 17:30:38 -0000 Content-Type: multipart/alternative; boundary=Apple-Mail-F1EA9285-49C7-42E9-8CDA-3711A6263233 Mime-Version: 1.0 (1.0) From: Christian Huitema X-Mailer: iPhone Mail (14B100) In-Reply-To: Date: Fri, 18 Nov 2016 07:30:36 -1000 Content-Transfer-Encoding: 7bit Message-Id: References: <1727072.YfzU8VvnnN@pintsize.usersys.redhat.com> To: Ira McDonald X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dP6iToxOOfkkkKBkEi+o3RqBn9PDoOhj/xzb7kHn/aQhIMekNi8AbP1K8LEdFLG4hl+E G0LkVe84GfmI/hX4rag2nRvX0MfW6lfweqbh+DYwGlugeeYNRP+TKatltgBEa/+k51CV8HOoCp+b WB2rXxPubplnbiDyBMUiEvUZuPnV+6xPoqikFlxGE5ethSvjIJZI+lxcZnIhduMqXEDVCZfDqcig OvSxdRnthmhn8Zn6kM3/7L/ISIACHsGTxvFo71PsH1QqniimNy9qh2Eko/GUK0vciBekfU6mwXfa SylReoz65OD2C5IJ2sa6HdMmGRMKuUeqX+EE9ftsEQ35CMRUE7Q9WvntXa9VPL9K4cA+8t3Xj/Lz Z5s/OJg1L2asZxEp4Bv7TWEUoKzFQfrYUezLRF4P3cD+yYsyYy0PbXJivfXYa4zafYJGo76gRHJN CirkfYeKydSIUY0HOcUIkoTyqcuDRIDLibiQ8pjP/rLDACMyE+XhWF028w059hjlWNOITDa6LxNU +V0EKPyMEBMkrKDU4kfxpqT7+EMydLi7baW0KlbI7odCZa1sbCHLgYdIPjNne2wo+JnzUL4YmPar JORNVBNenpsQr686JX7e X-Report-Abuse-To: spam@mx99.antispamcloud.com X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.10) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 17:31:38 -0000 --Apple-Mail-F1EA9285-49C7-42E9-8CDA-3711A6263233 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I prefer TLS 1.3, because is signals continuity with the ongoing TLS deploym= ent efforts. -- Christian Huitema=20 > On Nov 18, 2016, at 6:47 AM, Ira McDonald wrote:= >=20 > Hi, >=20 > +1 --- keep TLS 1.3 >=20 > Cheers, > - Ira >=20 >> On Fri, Nov 18, 2016 at 11:16 AM, Hubert Kario wrote:= >> On Friday, 18 November 2016 11:12:48 CET Sean Turner wrote: >> > At IETF 97, the chairs lead a discussion to resolve whether the WG shou= ld >> > rebrand TLS1.3 to something else. Slides can be found @ >> > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka= -pr6 >> > 12-01.pdf. >> > >> > The consensus in the room was to leave it as is, i.e., TLS1.3, and to n= ot >> > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decisi= on >> > on the list so please let the list know your top choice between: >> > >> > - Leave it TLS 1.3 >> > - Rebrand TLS 2.0 >> > - Rebrand TLS 2 >> > - Rebrand TLS 4 >>=20 >> Keep it at TLS 1.3. >>=20 >> TLS 2.0 and 2 are just too likely to be confused with SSL 2. >>=20 >> -- >> Regards, >> Hubert Kario >> Senior Quality Engineer, QE BaseOS Security team >> Web: www.cz.redhat.com >> Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail-F1EA9285-49C7-42E9-8CDA-3711A6263233 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
I prefer TLS 1.3, because is signals c= ontinuity with the ongoing TLS deployment efforts.

-- Christian Huite= ma 

On Nov 18, 2016, at 6:47 AM, Ira McDonald <blueroofmusic@gmail.com> wrote:
Hi,

+1 --- keep TLS 1.3

Cheers,
- Ira

On Fri, Nov 18, 2016 at 11:16 AM, Hubert Kari= o <hkario@redhat.com> wrote:
= On Friday, 18 November 2016 11:12:48 CET Sean Turner wrote:=
> At IETF 97, the chairs lead a discussion to resolve whether the WG shou= ld
> rebrand TLS1.3 to something else.  Slides can be found @
> https://www.ietf.org/<= wbr>proceedings/97/slides/slides-97-tls-rebranding-aka-pr6
> 12-01.pdf.
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to n= ot
> rebrand it to TLS 2.0, TLS 2, or TLS 4.  We need to confirm this d= ecision
> on the list so please let the list know your top choice between:
>
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4

Keep it at TLS 1.3.

TLS 2.0 and 2 are just too likely to be confused with SSL 2.

--
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


____________________= ___________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/lis= tinfo/tls
= --Apple-Mail-F1EA9285-49C7-42E9-8CDA-3711A6263233-- From nobody Fri Nov 18 09:47:36 2016 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 E57CC129686 for ; Fri, 18 Nov 2016 09:47:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ridF_-rgoFdB for ; Fri, 18 Nov 2016 09:47:33 -0800 (PST) Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABD1D129621 for ; Fri, 18 Nov 2016 09:47:33 -0800 (PST) Received: from pps.filterd (m0098414.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id uAIHigUG080270 for ; Fri, 18 Nov 2016 12:47:32 -0500 Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by mx0b-001b2d01.pphosted.com with ESMTP id 26t0ayj0rr-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Fri, 18 Nov 2016 12:47:32 -0500 Received: from localhost by e33.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 18 Nov 2016 10:47:31 -0700 Received: from d03dlp02.boulder.ibm.com (9.17.202.178) by e33.co.us.ibm.com (192.168.1.133) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 18 Nov 2016 10:47:30 -0700 X-IBM-Helo: d03dlp02.boulder.ibm.com X-IBM-MailFrom: dskern@us.ibm.com X-IBM-RcptTo: tls@ietf.org Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id 7083F3E4003E for ; Fri, 18 Nov 2016 10:47:29 -0700 (MST) Received: from b01ledav002.gho.pok.ibm.com (b01ledav002.gho.pok.ibm.com [9.57.199.107]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id uAIHlTV141877654 for ; Fri, 18 Nov 2016 17:47:29 GMT Received: from b01ledav002.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F2898124037 for ; Fri, 18 Nov 2016 12:47:28 -0500 (EST) Received: from d40lp02.lotus.com (unknown [9.32.8.79]) by b01ledav002.gho.pok.ibm.com (Postfix) with ESMTPS id D135512403F for ; Fri, 18 Nov 2016 12:47:28 -0500 (EST) Received: from localhost by d40lp02.lotus.com with XMail ESMTP for from ; Fri, 18 Nov 2016 12:47:24 -0500 Received: from smtp.notes.scniris.com (173.192.202.211) by d40lp02.lotus.com (192.147.107.239) with XMail ESMTP; (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128/128) Fri, 18 Nov 2016 12:47:21 -0500 Received: from localhost by smtp.notes.scniris.com with smtp.notes.scniris.com ESMTP for from ; Fri, 18 Nov 2016 17:47:25 -0000 Received: from irisa-smtp01.ir3.wdc01.isc4sb.com (10.102.14.125) by smtp.notes.scniris.com (10.102.16.214) with smtp.notes.scniris.com ESMTP; Fri, 18 Nov 2016 17:47:23 -0000 Received: from irisa-mail02.ir3.wdc01.isc4sb.com ([10.102.14.98]) by irisa-smtp01.ir3.wdc01.isc4sb.com with ESMTP id 2016111817474183-2370 ; Fri, 18 Nov 2016 17:47:41 +0000 In-Reply-To: References: To: tls@ietf.org MIME-Version: 1.0 X-KeepSent: 49ABE4FC:3044369E-0025806F:0060B728; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1FP7 Octobe4, 2013 From: "Dave Kern" Date: Fri, 18 Nov 2016 12:47:22 -0500 X-LLNOutbound: False X-TNEFEvaluated: 1 Content-Type: text/plain; charset="US-ASCII" x-cbid: 16111817-0008-0000-0000-0000061CC5B3 X-IBM-ISS-SpamDetectors: Score=0.40962; BY=0; FL=0; FP=0; FZ=0; HX=0; KW=0; PH=0; SC=0.40962; ST=0; TS=0; UL=0; ISC= X-IBM-ISS-DetailInfo: BY=3.00006100; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00782489; UDB=6.00377594; UTC=2016-11-18 17:47:23 x-cbparentid: 16111817-4546-0000-0000-000000F41170 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006100; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00782489; UDB=6.00377594; IPR=6.00559958; BA=6.00004892; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013369; XFM=3.00000011; UTC=2016-11-18 17:47:23 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00006100; HX=3.00000240; KW=3.00000007; PH=3.00000004; SC=3.00000189; SDB=6.00782489; UDB=6.00377594; IPR=6.00559958; BA=6.00004892; NDR=6.00000001; ZLA=6.00000005; ZF=6.00000009; ZB=6.00000000; ZP=6.00000000; ZH=6.00000000; ZU=6.00000002; MB=3.00013369; XFM=3.00000011; UTC=2016-11-18 17:47:31 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused Message-Id: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-11-18_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=1 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1609300000 definitions=main-1611180298 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 17:47:35 -0000 I am sick and tired of explaining to doc writers, UI designers, client admins, and developers that 1.2 >> 2, and this massive overhaul of the protocol merits more than a minor version bump in order to receive the public attention and migration effort that it deserves. TLS 2 and TLS 3 also have a high risk of confusion with SSLv2 and SSLv3 since most of the people who aren't on this mailing list refer to the protocol as "SSL/TLS" and panic over using TLS 1.2 when the media breathlessly reports that "all versions of SSL have been deprecated!" I'm in favor of TLS 4, and ignoring the minor version number (in the friendly text string, not the protocol field) moving forward. Thanks, dave From nobody Fri Nov 18 10:00:11 2016 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 0F50C12952F for ; Fri, 18 Nov 2016 10:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.922 X-Spam-Level: X-Spam-Status: No, score=-6.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 oSR6TNvkdL-0 for ; Fri, 18 Nov 2016 10:00:09 -0800 (PST) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 735571294F3 for ; Fri, 18 Nov 2016 10:00:09 -0800 (PST) Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 3tL5PM05S1z1HZR; Fri, 18 Nov 2016 19:00:07 +0100 (CET) X-purgate-ID: 152705::1479492007-00003836-A266B701/0/0 X-purgate-size: 418 X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate-type: clean X-SAP-SPAM-Status: clean Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3tL5PL3NJNzGp3P; Fri, 18 Nov 2016 19:00:06 +0100 (CET) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6794D1A58B; Fri, 18 Nov 2016 19:00:06 +0100 (CET) In-Reply-To: To: Christian Huitema Date: Fri, 18 Nov 2016 19:00:06 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20161118180006.6794D1A58B@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: mrex@sap.com 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, 18 Nov 2016 18:00:11 -0000 Christian Huitema wrote: > > I prefer TLS 1.3, because is signals continuity with the > ongoing TLS deployment efforts. As long as the awful hiding of the ContentType information in TLS Records remains in this protocol, it will *NOT* easily deploy as a replacement of TLSv1.2. I'm OK with TLS 4, but my real concern is the (current) lack of backwards compatibility of the TLS record format. -Martin From nobody Fri Nov 18 10:07:47 2016 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 58D8F12962C for ; Fri, 18 Nov 2016 10:07:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 sFHyzlWh_BUe for ; Fri, 18 Nov 2016 10:07:43 -0800 (PST) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id E86471295E3 for ; Fri, 18 Nov 2016 10:07:42 -0800 (PST) Received: (qmail 30058 invoked by uid 1017); 18 Nov 2016 18:07:40 -0000 Received: from unknown (unknown) by unknown with QMTP; 18 Nov 2016 18:07:40 -0000 Received: (qmail 16476 invoked by uid 1000); 18 Nov 2016 18:07:37 -0000 Date: 18 Nov 2016 18:07:37 -0000 Message-ID: <20161118180737.16475.qmail@cr.yp.to> Mail-Followup-To: tls@ietf.org From: "D. J. Bernstein" To: tls@ietf.org In-Reply-To: Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 18:07:45 -0000 The largest number of users have the least amount of information, and they see version numbers as part of various user interfaces. It's clear how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad) but 4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is supported). We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if this type of disaster happens to only 1% of site administrators, it strikes me as more important for security than any of the arguments that have been given for "TLS 1.3". So I would prefer "TLS 4". Yes, sure, we can try to educate people that TLS>SSL (but then we're fighting against tons of TLS=SSL messaging), or educate them to use server-testing tools (so that they can fix the problem afterwards---but I wonder whether anyone has analyzed the damage caused by running SSLv3 for a little while before switching the same keys to a newer protocol), and hope that this education fights against 3>1.3 more effectively than it fought against 3>1.2. But it's better to switch to a less error-prone interface that doesn't require additional education in the first place. ---Dan From nobody Fri Nov 18 11:29:23 2016 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 9F8E51294FE for ; Fri, 18 Nov 2016 11:29:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 qbVRbCa38q5y for ; Fri, 18 Nov 2016 11:29:17 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 32BA812965C for ; Fri, 18 Nov 2016 11:29:16 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id p66so105861213pga.2 for ; Fri, 18 Nov 2016 11:29:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YmhEfEdSeJ9QpHcroWF11WpS97XWFxOZatrMcs4msNY=; b=xSvk+I+lRPhmuInme2qscBYAu6IbbKFJA67PEppM/HNilsVMtlwluYCPoogW3nOO8i IxKh1w8CuNzY1q1a2yy4PaFUHTiF15xmEWVxTiOfRmxfQfrtIuvb9RULRyZ6882DKLWx OvCIFi7D8h/XMcuvFtzCSeYZXz7thuj0X5qRE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=YmhEfEdSeJ9QpHcroWF11WpS97XWFxOZatrMcs4msNY=; b=HM768ME97A7QkvCb6cdfKWaYFeSzvCDp2B6XB422FWNBb1PjK7Ugh5zkMaQ1HjaBgf zg2YYqAaphoTgptFRjVK1HvZwF4w+7OmJUzF/ENCg2Awx+C85EBSGNr0FHlvWAKN9FRh Tq6cGeg584xgVg1aLIMsRwCSMr/oybIN9OrLGDbi6sTc0omEoxCPBQwqrJNj6FUrVAtt v4PYrV8HjdmQ1lK9fmv4BZy0dkPJgSvsmKI5YydTBOtu80nYdRyPOUPwJxrw91qFK/Vh nW7RQ+BMtS3KmJHcwx9NZ++s+wZtFF67GGhoFEePdw4RWidHe26sDWUzXWT7E8Z1f6b8 Gi1Q== X-Gm-Message-State: AKaTC012EH/bnsDqExf8mpUlmsGtDhS8OdXmnuOrfXQjZ6WRpLCuwsPfHlM84qu3jrR8YRNh X-Received: by 10.99.65.65 with SMTP id o62mr2693806pga.73.1479497355322; Fri, 18 Nov 2016 11:29:15 -0800 (PST) Received: from ?IPv6:2601:645:8302:ef30:d94f:c7b2:5caa:14d9? ([2601:645:8302:ef30:d94f:c7b2:5caa:14d9]) by smtp.gmail.com with ESMTPSA id a1sm1683259pgf.16.2016.11.18.11.29.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 11:29:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Vlad Krasnov In-Reply-To: <20161118180737.16475.qmail@cr.yp.to> Date: Fri, 18 Nov 2016 11:29:13 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <555F1FCF-CB73-48D4-AC7C-A255EF3ACE2C@cloudflare.com> References: <20161118180737.16475.qmail@cr.yp.to> To: "D. J. Bernstein" X-Mailer: Apple Mail (2.3251) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 19:29:18 -0000 First: where can we see the study that proves people are indeed confused = that TLS > SSL? I don=E2=80=99t buy into that. Are people really = confused after 17 years of TLS? Second: I don=E2=80=99t think that the changes between TLS 1.3 and TLS = 1.2 are considered a major: just look at the difference between HTTP/2 = and HTTP/1 - those are completely different protocols. Most of TLS 1.3 could be implemented on top of TLS 1.2 with extensions = (the way it really looks, if you consider even client_version remains = the same). Third: There was *some* marketing on TLS 1.3, and changing the name now = will just tell the public the WG is confused and doesn=E2=80=99t know = what its doing. I vote for TLS 1.3. > On 18 Nov 2016, at 10:07, D. J. Bernstein wrote: >=20 > The largest number of users have the least amount of information, and > they see version numbers as part of various user interfaces. It's = clear > how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad) but > 4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is supported). >=20 > We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if this = type > of disaster happens to only 1% of site administrators, it strikes me = as > more important for security than any of the arguments that have been > given for "TLS 1.3". So I would prefer "TLS 4". >=20 > Yes, sure, we can try to educate people that TLS>SSL (but then we're > fighting against tons of TLS=3DSSL messaging), or educate them to use > server-testing tools (so that they can fix the problem = afterwards---but > I wonder whether anyone has analyzed the damage caused by running = SSLv3 > for a little while before switching the same keys to a newer = protocol), > and hope that this education fights against 3>1.3 more effectively = than > it fought against 3>1.2. But it's better to switch to a less = error-prone > interface that doesn't require additional education in the first = place. >=20 > ---Dan >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Nov 18 12:27:35 2016 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 410BB129508 for ; Fri, 18 Nov 2016 12:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BOnP75fO9O8w for ; Fri, 18 Nov 2016 12:27:33 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 8D9FE129496 for ; Fri, 18 Nov 2016 12:27:32 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id z62so101056329oiz.1 for ; Fri, 18 Nov 2016 12:27:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=0l610iDKZwfd1rHJIXt+sUJYPq4SRgHMlF+vxMAXhOc=; b=lgK1V4oilnOtOHnXQHqdiv3854/LPOgFt/NupM3CYGwJDF7o4XGet2E6eVIg9ttwRc CjG7XfVg9vwbdZJtKUxZl1dew9zIrU/UB77iFo0Oa4cUVCJR4Fvk+Pyal+Imc/LHdN96 0N9EdOnvk4dbEED/Aabk/ux3Q47qXzf2UIhop/c2kWSUEdH4uSHmqFXSekgqAgdpgGEA 4Cqrv2QbPZXFTI5n1UbCSDG+NCMLd/adApy73HHUWuRvhVEDTHDJohWcMPMVdfCZa0E6 ADL5GpOro2mn+Oa3vLYchrHVA7C055xZTKxPUygoMTdV8kczLPC6lvhl+3NRpOTC6prA 8rqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=0l610iDKZwfd1rHJIXt+sUJYPq4SRgHMlF+vxMAXhOc=; b=lvxkGzsq7+wt5JnVStH+U+Ilt5D8CtFWZxSWTzY2oxijzePBEWZATy+UI/vLZyS4hU PNH1wMTqQL6qN54RiRNbQfuL/jIBI8JO68b0VMSHZiG4bupppU/OabOebfPdtzbrQhY4 rvMd6jVA9O2xXHirWvY09DQmL+ch232nAalsT5+XJjQ9MuEli7CLZWP6+akxgF80AUVU 79CnZYkyc9Gx/jg9qjjNhQ0oKCEhU1+JlfsbzfkAnE3vGkCilKUPp3Ib4OHu+FKyNf6j 6KOXUnsnjUtRg0XxyrRXylBPeeLPuW7JRWaLF38c3qKgG2ljbryrLGj1bhr+/rb91Rza ADXw== X-Gm-Message-State: AKaTC03bTmZ74mW74WXxQhFM/XUdPB1snJyWPwXi9f4tH+RUbFObr1kwvcyYnUnd44Y57RY1MGnx28qQksg+uA== X-Received: by 10.157.35.74 with SMTP id k10mr1195144otd.26.1479500851784; Fri, 18 Nov 2016 12:27:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.153.4 with HTTP; Fri, 18 Nov 2016 12:26:37 -0800 (PST) From: Joseph Birr-Pixton Date: Fri, 18 Nov 2016 20:26:37 +0000 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 20:27:34 -0000 For what it's worth I would prefer TLS4. Cheers, Joe From nobody Fri Nov 18 12:47:23 2016 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 C4193129546 for ; Fri, 18 Nov 2016 12:47:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IN-s-tA4hLlS for ; Fri, 18 Nov 2016 12:47:20 -0800 (PST) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (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 462FA129503 for ; Fri, 18 Nov 2016 12:47:20 -0800 (PST) Received: by mail-it0-x22d.google.com with SMTP id j191so52338989ita.1 for ; Fri, 18 Nov 2016 12:47:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=2zTn3BUCuGCtpVcsvMhEGgbLdEc7vGMZdNcd6vdMUo4=; b=H/F+hYmc3wIk3JChEv3nB6UlwA6vtZARHywTOanY3S6SVY10FBkAxuy3wmN1cI/nQu EuoArol33TEfP43extzhH4h8+zWKV4/gKSEm6bIOnnNVyW4DINEmwPnbn+0cXQVtCmTJ ZAkFeVvYZX4E64mO/LAt6jwWTe0OEBC2ewVaynTU9h3wzaa3S4ywUZa+beGtNxEWTclc tayPSxe7OdrkiV7YVWEWipeCgFcbAJI0zKSMen3E9n4GK3wQe7+od5FmPKcwM9aSt+Kp wYWdQ5sMQ1V3YXQXW+LL00nJwxamixJkI0Kh6JBubjM/4rNwVV60EVy3B4/MI2lRa3rv YkgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=2zTn3BUCuGCtpVcsvMhEGgbLdEc7vGMZdNcd6vdMUo4=; b=RO1CgJA9wsaU0NJhgOgU3Tqcgse/cJ41o0GnNiPDl3LkoCU4aRTYo3WTo8ADtkv240 Rwx2p/go/7gz/zOvp8VrRCHaElb41XjC0BilvvJJ2fE6BHidhRE/QYkS4tlP7McIfy+T 83LN5N3Xzs3nQJBWQ5cqzaQkB/dctp8an8t8GIaEzP3Qo7bxp1NNKaWyC1MHS3oax39j escfPhwPQkuheV4+wo6ECKhSS7wFDpXGN6ElEgAB3gpPq9HevIBxJYxSCETTplXEd94d trC3LjNQIHLMUBz7zjxC5wPexuwVmaYxYvx6UCPgqHfxjKNhDz89EcCr/AqU2yPIl+Yw kfnQ== X-Gm-Message-State: AKaTC018zJ0+Fg1/Oz2TfQXiJNU55Wup/jt3BVOSpvBBwF+E+fzTYE4JYYq6iKRZPWQmoVqMilEZPJp7mumI4Q== X-Received: by 10.36.36.131 with SMTP id f125mr390481ita.2.1479502039555; Fri, 18 Nov 2016 12:47:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.41.5 with HTTP; Fri, 18 Nov 2016 12:47:18 -0800 (PST) In-Reply-To: References: From: Deb Cooley Date: Fri, 18 Nov 2016 15:47:18 -0500 Message-ID: To: Joseph Birr-Pixton Content-Type: multipart/alternative; boundary=001a1147c69c8322ab0541996991 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 20:47:22 -0000 --001a1147c69c8322ab0541996991 Content-Type: text/plain; charset=UTF-8 +1 for TLS 1.3 anything else is confusing to everybody (the term 'SSL' is still very common in the layman vocabulary) That said, if I had to pick a second choice, then TLS4 would be my choice. Deb Cooley On Fri, Nov 18, 2016 at 3:26 PM, Joseph Birr-Pixton wrote: > For what it's worth I would prefer TLS4. > > Cheers, > Joe > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1147c69c8322ab0541996991 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
+1 for TLS 1.3 anything else is confusing to eve= rybody (the term 'SSL' is still very common in the layman vocabular= y)

That said, if I had to pick a second choice, then TLS4 woul= d be my choice.

Deb Cooley

On Fri, Nov 18, 2016 at 3:26 PM, Joseph Bir= r-Pixton <jpixton@gmail.com> wrote:
For what it's worth I would prefer TLS4.

Cheers,
Joe

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1147c69c8322ab0541996991-- From nobody Fri Nov 18 13:01:55 2016 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 700B012978C for ; Fri, 18 Nov 2016 13:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 D7D779aIiDvv for ; Fri, 18 Nov 2016 13:00:42 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 645C41295DC for ; Fri, 18 Nov 2016 13:00:42 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C2D19496CA2; Fri, 18 Nov 2016 21:00:41 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id A3035496C83; Fri, 18 Nov 2016 21:00:41 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479502841; bh=96VVZO3bJrMap7IJW3TYmmb3uf3IJCro95mDj+CPw1k=; l=2596; h=From:To:CC:Date:References:In-Reply-To:From; b=AMP39Q2klD5u6YU9vx6qxIMXImZjM+RbPpvecQHVl5vgfUyrTcKjnRmff9nCwfMsg wlGW1sG3cCafhYwHF9OrkpoWpSksNflubONvU+ohW2Oo4AWzREBz3atgCOXY6dbEpU oHvafDRpFoLbGVOjwXJDCVKyuVEUrBDZpJrNyags= Received: from email.msg.corp.akamai.com (usma1ex-cas2.msg.corp.akamai.com [172.27.123.31]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 8A8621E07C; Fri, 18 Nov 2016 21:00:41 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 18 Nov 2016 16:00:40 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 18 Nov 2016 16:00:41 -0500 From: "Salz, Rich" To: Vlad Krasnov , "D. J. Bernstein" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDfXpiAgAAWzID//8A64A== Date: Fri, 18 Nov 2016 21:00:40 +0000 Message-ID: <51691c7b6a314319988719c0bb8bf456@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20161118180737.16475.qmail@cr.yp.to> <555F1FCF-CB73-48D4-AC7C-A255EF3ACE2C@cloudflare.com> In-Reply-To: <555F1FCF-CB73-48D4-AC7C-A255EF3ACE2C@cloudflare.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 21:00:44 -0000 DQo+IEZpcnN0OiB3aGVyZSBjYW4gd2Ugc2VlIHRoZSBzdHVkeSB0aGF0IHByb3ZlcyBwZW9wbGUg YXJlIGluZGVlZCBjb25mdXNlZA0KPiB0aGF0IFRMUyA+IFNTTD8gSSBkb27igJl0IGJ1eSBpbnRv IHRoYXQuIEFyZSBwZW9wbGUgcmVhbGx5IGNvbmZ1c2VkIGFmdGVyIDE3IHllYXJzDQo+IG9mIFRM Uz8NCg0KV2VsbCwgZm9yIGV4YW1wbGUsIHlvdXIgd2Vic2l0ZSBoYXMgdHdpY2UgYXMgbWFueSBt ZW50aW9ucyBvZiBTU0wgYXMgVExTLiAgV2h5PyAgV2h5IGRvbid0IHlvdSBoYXZlIGEgcHJvZHVj dCBjYWxsZWQgIlVuaXZlcnNhbCBUTFMiPyBUaGUgcmF0aW8gaXMgdGhlIHNhbWUgZm9yIGxldHNl bmNyeXB0by5vcmcuIFRMUyAxLjAgaGFkIGFscmVhZHkgZXhpc3RlZCBmb3IgbW9yZSB0aGVuIGEg ZGVjYWRlIGJlZm9yZSBlaXRoZXIgcGxhY2UgZXhpc3RlZC4gIEJUVywgYXQgZ29vZ2xlLCBpdCdz IDIwOjEsIGFuZCB0aGF0J3MganVzdCBnb29nbGUsIG5vdCB0aGUgd2ViLiAgKENvdW50cyB3ZXJl IGRvbmUgaW4gdGhlIG9idmlvdXMgZHVtYiB3YXkgInNpdGU6bGV0c2VuY3J5cHQub3JnIHRscyIg YW5kIHRoZW4gd2l0aCAic3NsIiBhbmQgbm90aW5nIHRoZSBzdW1tYXJ5IHN0YXRzIGF0IHRoZSB0 b3Agb2YgdGhlIHJldHVybiByZXN1bHRzLikgDQoNClBlb3BsZSBhcmUgY29uZnVzZWQgYmVjYXVz ZSB3ZSB0cmVhdCB0aGVtIGFzIHRoZSBzYW1lIHRoaW5nLiANCg0KPiBUaGlyZDogVGhlcmUgd2Fz ICpzb21lKiBtYXJrZXRpbmcgb24gVExTIDEuMywgYW5kIGNoYW5naW5nIHRoZSBuYW1lIG5vdw0K PiB3aWxsIGp1c3QgdGVsbCB0aGUgcHVibGljIHRoZSBXRyBpcyBjb25mdXNlZCBhbmQgZG9lc27i gJl0IGtub3cgd2hhdCBpdHMgZG9pbmcuDQoNClRoZSBwdWJsaWMgaGFzIG5vIGlkZWEgd2hhdCB0 aGUgV0cgaXMuDQoNCkxpc3RlbiB0byB0aGUgbm9uLWRldmVsb3BlcnMgd2hvIGhhdmUgcG9zdGVk IGhlcmUuICBWZXJzaW9uIG51bWJlcnMgbWF0dGVyIHRvIGxvdy1pbmZvcm1hdGlvbiBkZWNpc2lv biBtYWtlcnMsIHdobyBuZWVkIHNvbWV0aGluZyBxdWljayBhbmQgc2ltcGxlIHRvIGdyYWIgb24g dG8uICBJdCdzIHNpbGx5LCBidXQgc28gaXMgdGhlIHJlYWwgd29ybGQuICBUTFMgNCBvciBUTFMg NC4wICBUaGUgdGVjaG5vbG9neSB3aWxsIGdldCBtb3JlIGV4cG9zdXJlIGFzIHRoZSB0cmFkZSBw cmVzcyBleHBsYWlucyB3aHkgdGhlIG5ldyB2ZXJzaW9uIG51bWJlciAtLSBpdCdzIHNvIG11Y2gg bW9yZSBzZWN1cmUgdGhhbiB3aGF0IHdlJ3ZlIGhhZCBiZWZvcmUgLS0gYW5kIHRoZXJlZm9yZSB0 aGUgIm5ldyBUTFMiIHdpbGwgZ2V0IG1vcmUgbWluZHNoYXJlLiAgQW5kIHRoZXJlZm9yZSBhZG9w dGlvbiB3aWxsIGJlIG1vcmUgcmFwaWQuICBUaGF0J3Mgd2hhdCB3ZSB3YW50LCByaWdodD8gIE9y IGFyZSB3ZSBzYXRpc2ZpZWQgd2l0aCBqdXN0IGxldHRpbmcgdHdvIGJyb3dzZXIncyBjYW5hcnkg YnVpbGRzIHB1bGwgdGhlIGVudGlyZSBJbnRlcm5ldCBmb3J3YXJkPw0KDQpZZXMgaXQgd2lsIGJl IGluY29udmVuaWVudC4gIFN1Y2sgaXQgdXAsIGJ1dHRlcmN1cC4gIEF0IHRoZSBJRVRGIHRoaXMg d2VlayB3ZSBoYWQgcGVvcGxlIHRlbGxpbmcgcGVvcGxlIGZyb20gYW4gZW50aXJlIGluZHVzdHJ5 IHNlZ21lbnQgInRvbyBiYWQsIHRoaXMgaXMgdGhlIHJpZ2h0IHRoaW5nIHRvIGRvOyBhZGFwdC4i ICAoSSBleGFnZ2VyYXRlIGZvciBlZmZlY3QgaGVyZS4pICBBbmQgbm93IHdlJ3JlIGdvaW5nIHRv IGNvbmZ1c2UgdGhlIHdvcmxkIGJlY2F1c2Ugd2UgY2FuJ3QgY2hhbmdlIHRoZSBuYW1lIG9mIGEg R2l0SHViIHJlcG8sIGEgZmV3ICNkZWZpbmUncyBpbiBzb3VyY2UsIGFuZCBtYXliZSBhIFdpa2lw ZWRpYSBwYWdlPyANCg== From nobody Fri Nov 18 13:19:11 2016 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 64675129424 for ; Fri, 18 Nov 2016 13:19:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 TL7cGpMCKmiT for ; Fri, 18 Nov 2016 13:19:07 -0800 (PST) Received: from mail-pf0-x22f.google.com (mail-pf0-x22f.google.com [IPv6:2607:f8b0:400e:c00::22f]) (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 35ECF127078 for ; Fri, 18 Nov 2016 13:19:07 -0800 (PST) Received: by mail-pf0-x22f.google.com with SMTP id d2so56275541pfd.0 for ; Fri, 18 Nov 2016 13:19:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MzOc3MXs6Fko83AfQCpYISj9hYWNhOuhSYecV1dXDi8=; b=r2aLrvMG6FH5I/d7Q7GUhzSC98R4vN3j7PNv2qzpg9oFUxz/xZdPbCaoj32bMr6BIJ KqwCInmAyz9fx6a4DVyQZ1ZAjNp7ZPJ9EIVIOzujQMo6uPJZNNvGGVAG54XjcZemwyoD KdZ9aK7ZjyUve8LkvT0PoS6Uh8yKGFQR2ZPZs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=MzOc3MXs6Fko83AfQCpYISj9hYWNhOuhSYecV1dXDi8=; b=iO3P6Bz+d6QTv/cBFczVp0YMbPTt9G1jdCJ3TPQS02H4oKza1wl6gHOndIRHB6U1lI fychcVevmduWp1CMdZvWMWU374Jutn0BQuHK9UF4Qo0TRPxoyCHHp1cKZ4Y/Gje71ntJ 78h0ROM6dIX9ODccAsAe/UFtu4pOVRzy/UOaM5mC7IbORJW6WyfGuifoEhbYqJgDG44l 6ecJMfXyFH1H6SUN4ntFBvPNaZ0df7DZW9iTsUEyzHWe7SlEotOQjNofU3gYcx7jOhJ5 d8oTtPxS/xtdmh1yglvULkUW99FcS2zgPoI8OV8ZdiNAq8kPSUs5u/yXEgUZKE28pA/h y5Ww== X-Gm-Message-State: AKaTC03YzdDtqP4xR8G7Y6YUys4bFt6xAqA0p1Qg9bo4EHe0HeWE0w3yw2WtnCTMf7P7b7j0 X-Received: by 10.99.129.200 with SMTP id t191mr3475885pgd.180.1479503946383; Fri, 18 Nov 2016 13:19:06 -0800 (PST) Received: from [6.218.217.106] ([172.56.38.177]) by smtp.gmail.com with ESMTPSA id q9sm20052677pfg.47.2016.11.18.13.19.05 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Nov 2016 13:19:05 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Vlad Krasnov X-Mailer: iPhone Mail (14A456) In-Reply-To: <51691c7b6a314319988719c0bb8bf456@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Fri, 18 Nov 2016 13:19:04 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <748B7799-7B8B-42A6-AB2C-C34971367B20@cloudflare.com> References: <20161118180737.16475.qmail@cr.yp.to> <555F1FCF-CB73-48D4-AC7C-A255EF3ACE2C@cloudflare.com> <51691c7b6a314319988719c0bb8bf456@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Archived-At: Cc: "D. J. Bernstein" , "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 21:19:09 -0000 > Well, for example, your website has twice as many mentions of SSL as TLS. = Why? Why don't you have a product called "Universal TLS"? The ratio is the= same for letsencrypto.org. TLS 1.0 had already existed for more then a deca= de before either place existed. BTW, at google, it's 20:1, and that's just g= oogle, not the web. (Counts were done in the obvious dumb way "site:letsenc= rypt.org tls" and then with "ssl" and noting the summary stats at the top of= the return results.)=20 >=20 > People are confused because we treat them as the same thing.=20 Well, if the result of the confusion would be people *disabling* TLS 1.* in f= avor of SSL 3.0, they would discover very quickly what is TLS, and why no ma= jor browser works for them. From nobody Fri Nov 18 13:25:07 2016 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 54B29129569 for ; Fri, 18 Nov 2016 13:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 e7mEjwp5SKVR for ; Fri, 18 Nov 2016 13:25:04 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1AF126CD8 for ; Fri, 18 Nov 2016 13:25:04 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AA91E433493; Fri, 18 Nov 2016 21:25:03 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 93FBF43348D; Fri, 18 Nov 2016 21:25:03 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479504303; bh=3jbukNZsJxStY/nkCwb7rRVVlXbCiRrSIwFQGPsASeM=; l=241; h=From:To:CC:Date:References:In-Reply-To:From; b=wz7N/wms1E4c/sf4JOWk2BQqzLUnbT0ppRiokNFkqtzei0yqZPnCp7JwaGBOZXAXI BsLjBVXoR/3O3ARYebFHxbsxh+M0o2jX2EUlwW2JMV77zL6ksotsNytijRy0imMYB5 qmbBOQTTcajGZ4KmpwIL0gJdPinclhpFkYsyKGnc= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 916D51FC9B; Fri, 18 Nov 2016 21:25:03 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 18 Nov 2016 16:25:03 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 18 Nov 2016 16:25:03 -0500 From: "Salz, Rich" To: Vlad Krasnov Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDfXpiAgAAWzID//8A64IAAXncA//+tq5A= Date: Fri, 18 Nov 2016 21:25:02 +0000 Message-ID: <62cca052d6764b45933e3b54def89c2a@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20161118180737.16475.qmail@cr.yp.to> <555F1FCF-CB73-48D4-AC7C-A255EF3ACE2C@cloudflare.com> <51691c7b6a314319988719c0bb8bf456@usma1ex-dag1mb1.msg.corp.akamai.com> <748B7799-7B8B-42A6-AB2C-C34971367B20@cloudflare.com> In-Reply-To: <748B7799-7B8B-42A6-AB2C-C34971367B20@cloudflare.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.81] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "D. J. Bernstein" , "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 21:25:05 -0000 > Well, if the result of the confusion would be people *disabling* TLS 1.* = in > favor of SSL 3.0, they would discover very quickly what is TLS, and why n= o > major browser works for them. People changing browser settings? Really? From eftychios.theodorakis@gmail.com Fri Nov 18 13:36:08 2016 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 D7EDA12959B for ; Fri, 18 Nov 2016 13:36:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAre8zUBeSnx for ; Fri, 18 Nov 2016 13:36:07 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 1EB3A129405 for ; Fri, 18 Nov 2016 13:36:07 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id b35so181663570uaa.3 for ; Fri, 18 Nov 2016 13:36:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=dGQEwRGZcwYZZTlrmnsyY/hgfYr/QvYe8Pd7prvxLpc=; b=r1jtJ0rWvr8Ueq3XCelY+VGMK91y2+nFELnApHjQkBzX+PJ5kjhh8YTug9CcPQP5zr GKtG7nuuS4ukKtBm3gRYcUMpoHwArPNPHFmdBlFS/xLg/f22GdnBhrn49kKYwKs8d1BU CZ5GrDm7KXL7pyTEhvFRjDcllmK6ECehyIuKtXeajB0yQXwKqOIIOaLBEPyyOYe+lDKV vXL+ax6f7BwlGphqh5fFtynrRJ+c/UeIcKdnJbQfuvidVr42jG0mHVsbrsXGpwuMc/lA beC730Exf1Xwfm9O9tQ3thwGbabCrSLV5us7TZlR3kKQMOkaO9nuFulXYcNJlOAFnrU/ YYMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=dGQEwRGZcwYZZTlrmnsyY/hgfYr/QvYe8Pd7prvxLpc=; b=FBf2W7Dc5YXcplcNce1IjQRpioog87VN0aK8eCQCOrCErhxlhwM5f/nN5NNeoEKDLc trqw1Cy046fuN/KQWPBieZBgakFywnUEi7AiCUTUNZyQ6jBNzU9MiJAWZZlEWrQEyWAc Si7I7kWhmRbmkhgC00sW/bunA7MOqZ1N7mNeE7+nLwbKwEXl0M7tv+eVefjppqXVpkG2 MVgR1eD6LESfG8iKrsGKrjz/ZvV0v46ihZFRYj8CkrIcN7voKQbnk3ysMg28PdeVQda7 t4wT1IhoW9o7rjNDUXaXRSILPpc7lB4+ls2oRgTV756cnpixYefTgeoqxeRMS3z1UNpA yVPw== X-Gm-Message-State: AKaTC00UZoFjhRz9WsVl9pfbaCdLVI1a6O3eEP2v9wJI7U3Tr58ylX0ooY3e9MujrpKhRDlrdcBB+Mvw1mLx1Q== X-Received: by 10.159.36.244 with SMTP id 107mr1039347uar.51.1479504966098; Fri, 18 Nov 2016 13:36:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.167.66 with HTTP; Fri, 18 Nov 2016 13:36:05 -0800 (PST) In-Reply-To: <20161118180737.16475.qmail@cr.yp.to> References: <20161118180737.16475.qmail@cr.yp.to> From: Eftychios Theodorakis Date: Fri, 18 Nov 2016 13:36:05 -0800 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a113f0fa4f2a5a105419a17c9 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 21:37:22 -0000 --001a113f0fa4f2a5a105419a17c9 Content-Type: text/plain; charset=UTF-8 It is imprinted in people's mind that minor version numbering = small improvements and compatibility. People for better or worse see a minor version as minor improvements and often disregard them considering the effort versus the payout - even if that is a single configuration change. That's how they learned from non security related projects. > I prefer TLS 1.3, because is signals continuity with the > ongoing TLS deployment efforts. The alternative suggestion (4) also signals the ongoing efforts. True it does hint on possible incompatibility; but is this not an honest versioning then? I think educating people is a good cause, but that's not enough. One has to account for all the real life anecdotes mentioned above. If people were good and fully informed decision makers there would not be a need for "do not press this red button" signs. I am not sure what will end up being the better version, but I am certain that 1.3 will be disregarded as a minor change - it is not. My suggestion is for TLS 4. 2016-11-18 10:07 GMT-08:00 D. J. Bernstein : > The largest number of users have the least amount of information, and > they see version numbers as part of various user interfaces. It's clear > how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad) but > 4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is supported). > > We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if this type > of disaster happens to only 1% of site administrators, it strikes me as > more important for security than any of the arguments that have been > given for "TLS 1.3". So I would prefer "TLS 4". > > Yes, sure, we can try to educate people that TLS>SSL (but then we're > fighting against tons of TLS=SSL messaging), or educate them to use > server-testing tools (so that they can fix the problem afterwards---but > I wonder whether anyone has analyzed the damage caused by running SSLv3 > for a little while before switching the same keys to a newer protocol), > and hope that this education fights against 3>1.3 more effectively than > it fought against 3>1.2. But it's better to switch to a less error-prone > interface that doesn't require additional education in the first place. > > ---Dan > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113f0fa4f2a5a105419a17c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It is imprinted in people's mind that minor version nu= mbering =3D small improvements and compatibility. People for better or wors= e see a minor version as minor improvements and often disregard them consid= ering the effort versus the payout - even if that is a single configuration= change. That's how they learned from non security related projects.

&g= t; I prefer TLS 1.3, because is signals continuity with the
> ongoing TLS deployment efforts.

= The alternative suggest= ion (4) also signals the ongoing efforts. True it does hint on possible inc= ompatibility; but is this not an honest versioning then?
<= span style=3D"color:rgb(80,0,80);font-size:12.8px">
I think educating pe= ople is a good cause, but that's not enough. One has to account for all= the real life anecdotes mentioned above. If people were good and fully inf= ormed decision makers there would not be a need for "do not press this= red button" signs.=C2=A0

I am not sure what will end up b= eing the better version, but I am certain that 1.3 will be disregarded as a= minor change - it is not.=C2=A0My suggestion is for TLS 4.


2016-11-18 10:0= 7 GMT-08:00 D. J. Bernstein <djb@cr.yp.to>:
The largest number of users have the least amount of informat= ion, and
they see version numbers as part of various user interfaces. It's clear=
how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad)= but
4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is suppor= ted).

We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if = this type
of disaster happens to only 1% of site administrators, it strikes me as
more important for security than any of the arguments that have been
given for "TLS 1.3". So I would prefer "TLS 4".

Yes, sure, we can try to educate people that TLS>SSL (but then we're=
fighting against tons of TLS=3DSSL messaging), or educate them to use
server-testing tools (so that they can fix the problem afterwards---but
I wonder whether anyone has analyzed the damage caused by running SSLv3
for a little while before switching the same keys to a newer protocol),
and hope that this education fights against 3>1.3 more effectively than<= br> it fought against 3>1.2. But it's better to switch to a less error-p= rone
interface that doesn't require additional education in the first place.=

---Dan

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a113f0fa4f2a5a105419a17c9-- From nobody Fri Nov 18 13:42:42 2016 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 B98671295DC for ; Fri, 18 Nov 2016 13:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 OiCLYvOL7YT6 for ; Fri, 18 Nov 2016 13:42:40 -0800 (PST) Received: from mail-pg0-x22c.google.com (mail-pg0-x22c.google.com [IPv6:2607:f8b0:400e:c05::22c]) (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 A8E901295D2 for ; Fri, 18 Nov 2016 13:42:40 -0800 (PST) Received: by mail-pg0-x22c.google.com with SMTP id 3so106934262pgd.0 for ; Fri, 18 Nov 2016 13:42:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+6bA4iaKApaLTfJTz9Ms+1DpOjgKu8d7BwjRCHMcwgE=; b=Oly1zLXJ8gjeJtx9/IrGsRE8CP0daNeECfAgrMvfk9kOB8Uw2LMR9gXkiPoFlCCM9W jmRTNNBHlcMPp7VleDM3K2rlJgG1CTJeAzqeoDFzWdhMiO8VXdJJ03zMtFs2PIr631xS dI9YtXNAZ7/V4xiBmxvfvOWl/tEGDp0QvyhG8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=+6bA4iaKApaLTfJTz9Ms+1DpOjgKu8d7BwjRCHMcwgE=; b=eOc++DGZmCoDWb+i93181dT5a2+MHqnzC45Q8xGHXp76qGCEP39Ru1W09zonR0a8p9 kYRca6r9W1zBfephwgILICOkhESr+ftuP2qs/7J7ZfHuF2wNFU6quB/eatowTYziGVuX BMFSjBPe4NhVi3sna3QR09xC+olfy1lILUZS3RCZ5l8+uu/IoALI92UnMVLUCwb7wiTK tC8qCq7uIDaH3kB+6pCxNdmhdeHccXod9rpknSTeCYRUEtFd5Kw+V30XVwTwwA3md+VQ SkUPnC3nhzxsVvf5ezFC04zy7reaZBFPnY4/ivtI7H2ZBfKKCqGCx/QgdHrFSw9SwjZC tM6w== X-Gm-Message-State: AKaTC01ugOtfE0FxwRPCLvagjdgAjg01M3tTVM8ugG0/SS6OCodyQRCvo2DXCT9umL1xyA7E X-Received: by 10.99.219.21 with SMTP id e21mr3750541pgg.136.1479505359756; Fri, 18 Nov 2016 13:42:39 -0800 (PST) Received: from ?IPv6:2607:fb90:2779:9f74:dcd0:fd13:368a:f370? ([2607:fb90:2779:9f74:dcd0:fd13:368a:f370]) by smtp.gmail.com with ESMTPSA id c22sm2011124pgn.12.2016.11.18.13.42.39 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Nov 2016 13:42:39 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Vlad Krasnov X-Mailer: iPhone Mail (14A456) In-Reply-To: <62cca052d6764b45933e3b54def89c2a@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Fri, 18 Nov 2016 13:42:38 -0800 Content-Transfer-Encoding: 7bit Message-Id: <43C382B2-33F2-46E7-B42E-2815A534893A@cloudflare.com> References: <20161118180737.16475.qmail@cr.yp.to> <555F1FCF-CB73-48D4-AC7C-A255EF3ACE2C@cloudflare.com> <51691c7b6a314319988719c0bb8bf456@usma1ex-dag1mb1.msg.corp.akamai.com> <748B7799-7B8B-42A6-AB2C-C34971367B20@cloudflare.com> <62cca052d6764b45933e3b54def89c2a@usma1ex-dag1mb1.msg.corp.akamai.com> To: "Salz, Rich" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 21:42:41 -0000 > People changing browser settings? Really? I was thinking about site admins. From nobody Fri Nov 18 13:53:57 2016 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 579A1129490 for ; Fri, 18 Nov 2016 13:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001] autolearn=ham autolearn_force=no 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 ZNUBk6cdF4ZL for ; Fri, 18 Nov 2016 13:53:54 -0800 (PST) Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA28E12946B for ; Fri, 18 Nov 2016 13:53:53 -0800 (PST) Received: from macbook-pro-de-julien-elie.home ([92.170.5.52]) by mwinf5d57 with ME id 9Ztq1u00417Lgi403Ztr6b; Fri, 18 Nov 2016 22:53:51 +0100 X-ME-Helo: macbook-pro-de-julien-elie.home X-ME-Auth: anVsaWVuLmVsaWU0ODdAd2FuYWRvby5mcg== X-ME-Date: Fri, 18 Nov 2016 22:53:51 +0100 X-ME-IP: 92.170.5.52 To: tls@ietf.org References: From: =?UTF-8?Q?Julien_=c3=89LIE?= Organization: TrigoFACILE -- http://www.trigofacile.com/ Message-ID: <4c199cbb-caaa-2a83-88f1-f7493d5a4be0@trigofacile.com> Date: Fri, 18 Nov 2016 22:53:50 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 21:53:56 -0000 Hi all, > The consensus in the room was to leave it as is, i.e., TLS1.3, and > tonot rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this > decision on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 Is there a reason why TLS 4.0 was not proposed? I would indeed vote for TLS 4.0 (I believe minor versions are useful to keep; bumping the major version should occur only when there are disruptive changes). TLS 4.0 gives people a stronger signal that it is a "must-have" (compared to 1.3), and prevent people from being confused by SSL 2 and 3. P.-S.: I would also suggest to use the TLS 1.3 name for "TLS 1.2 LTS". -- Julien ÉLIE « Ce que j'aime chez vous, c'est que vous savez jusqu'où on va trop loin. » (Cocteau) From nobody Fri Nov 18 14:18:07 2016 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 DAA2D129437 for ; Fri, 18 Nov 2016 14:18:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NP9PsTci5bsr for ; Fri, 18 Nov 2016 14:18:04 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 1D5D212956A for ; Fri, 18 Nov 2016 14:18:04 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id x190so281887668qkb.0 for ; Fri, 18 Nov 2016 14:18:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5OYsZknvi7mdIxF4NdJPcINefKutsqmZjdZuMhKrnrM=; b=NAGCCjsdvLmo3FvEW4iWmArf9ZzkrcmikxJz+qmDO0+lLOl+YLe2sJPuSyU06pKwvr /6xgHktFCtAdcnys5AGZX23NFX+NWvNBkj0A+k2ysOiTHHdtCnpb7SPplpQscjvgkHVm n0iFtDoF9TTPkiejs7unU4+ltRnTNEOSP1C/j/aIsM37UhPe2bMx9X2/GfhdeUcI+RhI WWAu1BMCPWmKwJ3yHovve86fB3njrs+UUvq+HloaC6X7KqN+gHVUct0ogOMA5DJIC5KX C8Mb3TKt/jhmc25J9D3V04HQmKni701KvgIHFBtzLNpVv0cXHQAQfpY62KJPpJo2G9qr q39Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5OYsZknvi7mdIxF4NdJPcINefKutsqmZjdZuMhKrnrM=; b=Yof/mE0+7UTxtOzYD34ZY/XxL4ULZHZzX40JgEBSc2NSgctCVTz1aY8FoCSr8fuTuV pzdkxAR2opI0PePXbtZUnVr7VEqXdDf3g50NV5O2Zw5RP5tCTTd3HlPbPBpXs7uQtXsa 4UF99oDro06XsCIWmQUKL4i5Rvp3mmV7X/XqUkdmFvwIEnssCltQx5t/JdA2jTmLKlaR gsqx1YOIY9tN8w0euz45DajLN20CEl+cYx3bIPz9TOn9bK3ynEs75O8mwK4qEQvKCe/z RBLB7yRoWJe8+Ka0PIM7NseC48m1enMnDmlSz2sr6UHUFsJ6/caV4RrVDGm9L7ROa46V DEXg== X-Gm-Message-State: AKaTC00NEqei4y63ZySWlCEM0K+e0R/Kfi9A4e0H34/5he03c5GfPcIdxcswJACYiNhhkHe6W/W8kBCf6Zqrtg== X-Received: by 10.55.12.2 with SMTP id 2mr2612143qkm.68.1479507483248; Fri, 18 Nov 2016 14:18:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.7 with HTTP; Fri, 18 Nov 2016 14:18:02 -0800 (PST) Received: by 10.140.85.7 with HTTP; Fri, 18 Nov 2016 14:18:02 -0800 (PST) In-Reply-To: References: <1479463783973.10653@cs.auckland.ac.nz> From: Martin Thomson Date: Sat, 19 Nov 2016 07:18:02 +0900 Message-ID: To: Peter Gutmann Content-Type: multipart/alternative; boundary=001a114c5c9efb4cc205419aadb5 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 22:18:06 -0000 --001a114c5c9efb4cc205419aadb5 Content-Type: text/plain; charset=UTF-8 On 18 Nov 2016 21:10, "Peter Gutmann" wrote: > Which is kind of odd, because the consensus on the list when it was debated > here a while back was to not call it 1.3. Some of us stayed quiet for that conversation. I might speculate that it was because it wasn't a constructive discussion. In the end, it's just a label. --001a114c5c9efb4cc205419aadb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On 18 Nov 2016 21:10, "Peter Gutmann" <pgut001@cs.auckland.ac.nz> wrote:
> Which is kind of odd, because the consensus on the list when it was de= bated
> here a while back was to not call it 1.3.=C2=A0

Some of us stayed quiet for that conversation. I might specu= late that it was because it wasn't a constructive discussion.

In the end, it's just a label.

--001a114c5c9efb4cc205419aadb5-- From nobody Fri Nov 18 14:22:00 2016 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 6654212956A for ; Fri, 18 Nov 2016 14:21:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 tvsWWY29D1Da for ; Fri, 18 Nov 2016 14:21:57 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 65D2E129437 for ; Fri, 18 Nov 2016 14:21:57 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C30A0462B16; Fri, 18 Nov 2016 22:21:56 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id AC9ED462B13; Fri, 18 Nov 2016 22:21:56 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479507716; bh=6KXg5+/CHG8Wl0eAqvms37HI5kMDuoAtkE01qYFn4mY=; l=526; h=From:To:CC:Date:References:In-Reply-To:From; b=QlOJJaJkV94CKSXdd0ypls+OlPchkDUVnwLHwxvi0ez9eamYy30AQ2VO1hvHSaUVE RtlaTWdTwE6eWbi1hAZ4iTNpR6cSETW5OA8j492cj0VX9PAJ0TNZC+BRyRrUeuMbWD CcF3z1IRzafYcd+ASTCELSuRT1YtOeAqNsF0BK9U= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id A7F391FC88; Fri, 18 Nov 2016 22:21:56 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 18 Nov 2016 17:21:55 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Fri, 18 Nov 2016 17:21:55 -0500 From: "Salz, Rich" To: Martin Thomson , Peter Gutmann Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDe2RwAgAB3sIeAAABrkA== Date: Fri, 18 Nov 2016 22:21:55 +0000 Message-ID: <3248bd3f264d423196a352e0ef5458a5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1479463783973.10653@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.115.81] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 22:21:58 -0000 PkluIHRoZSBlbmQsIGl0J3MganVzdCBhIGxhYmVsLg0KDQpBbmQgc29tZSBmb2xrcyBoZXJlIGhh dmUgdHJpZWQgdG8gZXhwbGFpbiB3aHkgbGFiZWxzIG1hdHRlci4gIElmIHlvdSBkb24ndCBmaW5k IHRob3NlIGFyZ3VtZW50cyBjb21wZWxsaW5nLCB0aGF0J3MgZmluZS4gIEJ1dCBpZiBpdCdzIHJl YWxseSAianVzdCIgYSBsYWJlbCB0byB5b3UsIHRoZW4gSSdsbCBhc3N1bWUgd2UndmUgc2VlbiB5 b3VyIGxhc3QgcG9zdCBvbiB0aGlzIHRocmVhZD8gOikNCiANCi0tICANClNlbmlvciBBcmNoaXRl Y3QsIEFrYW1haSBUZWNobm9sb2dpZXMNCk1lbWJlciwgT3BlblNTTCBEZXYgVGVhbQ0KSU06IHJp Y2hzYWx6QGphYmJlci5hdCBUd2l0dGVyOiBSaWNoU2Fseg0KDQoNCg== From nobody Fri Nov 18 14:33:18 2016 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 D6D191294D1 for ; Fri, 18 Nov 2016 14:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.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 SIgYaTczkW_K for ; Fri, 18 Nov 2016 14:33:15 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp1.pobox.com [64.147.108.70]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 120BD129456 for ; Fri, 18 Nov 2016 14:33:14 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id C229F50F0A for ; Fri, 18 Nov 2016 17:33:13 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to :content-type; s=sasl; bh=EToT/rLI0opGIMvufPnMJOJolRg=; b=oYjdUX q99ZywGs1HgWhiy8rOQS3U+QFvDoB+5KeB4Eylfsp8tq3UnWj7mqyrkdg22C1AVi W2M5krsi5j5Is/WakiYwR3sryLxWRWI9ybl/5OCSv1lj6NT2xhifbjgppvcvUKJx JaPo3RoL2qg3N1UyEtf+ndJmJZ4z6+R3rwQl4= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id BAC6250F09 for ; Fri, 18 Nov 2016 17:33:13 -0500 (EST) Received: from mail-qk0-f172.google.com (unknown [209.85.220.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 6643A50F07 for ; Fri, 18 Nov 2016 17:33:13 -0500 (EST) Received: by mail-qk0-f172.google.com with SMTP id q130so282741182qke.1 for ; Fri, 18 Nov 2016 14:33:13 -0800 (PST) X-Gm-Message-State: AKaTC033kWqMkc2hc2Z3jKX9w65AMpEWmpYxORJV2cn6A0mbPCTsYn/63fl+CfQIN7tn+2DlRh3HohaQoUUxjw== X-Received: by 10.55.200.149 with SMTP id t21mr2676040qkl.214.1479508392803; Fri, 18 Nov 2016 14:33:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.44.205 with HTTP; Fri, 18 Nov 2016 14:32:32 -0800 (PST) In-Reply-To: <20161118180737.16475.qmail@cr.yp.to> References: <20161118180737.16475.qmail@cr.yp.to> From: Eric Mill Date: Fri, 18 Nov 2016 17:32:32 -0500 X-Gmail-Original-Message-ID: Message-ID: To: "" Content-Type: multipart/alternative; boundary=001a113d58f4320a2205419ae45c X-Pobox-Relay-ID: FDD57B3C-ADDE-11E6-ACC9-987C12518317-82875391!pb-smtp1.pobox.com Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 22:33:17 -0000 --001a113d58f4320a2205419ae45c Content-Type: text/plain; charset=UTF-8 It seems like TLS 2 and TLS 2.0 have very little support, so it's really just deciding between: TLS 1.3 TLS 4 (or maybe 4.0) I'll just amplify Rich's and djb's points by noting that the cost of switching away from TLS 1.3 really only affects a very small number of people -- really just the people in and around this WG. There is a much, much larger universe of people who will make deployment and implementation decisions, with varying attention span and degrees of skill, and I think they're best served with a clean start of an unambiguous version number. Just because it feels uncomfortable to us doesn't mean it will feel uncomfortable to the larger technical/enterprise community who don't really *care* about the versioning scheme, they just need to make some decisions and move on. -- Eric On Fri, Nov 18, 2016 at 1:07 PM, D. J. Bernstein wrote: > The largest number of users have the least amount of information, and > they see version numbers as part of various user interfaces. It's clear > how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad) but > 4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is supported). > > We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if this type > of disaster happens to only 1% of site administrators, it strikes me as > more important for security than any of the arguments that have been > given for "TLS 1.3". So I would prefer "TLS 4". > > Yes, sure, we can try to educate people that TLS>SSL (but then we're > fighting against tons of TLS=SSL messaging), or educate them to use > server-testing tools (so that they can fix the problem afterwards---but > I wonder whether anyone has analyzed the damage caused by running SSLv3 > for a little while before switching the same keys to a newer protocol), > and hope that this education fights against 3>1.3 more effectively than > it fought against 3>1.2. But it's better to switch to a less error-prone > interface that doesn't require additional education in the first place. > > ---Dan > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- konklone.com | @konklone --001a113d58f4320a2205419ae45c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It seems like TLS 2 and TLS 2.0 have very little support, = so it's really just deciding between:

TLS 1.3
<= div>TLS 4 (or maybe 4.0)

I'll just amplify Ric= h's and djb's points by noting that the cost of switching away from= TLS 1.3 really only affects a very small number of people -- really just t= he people in and around this WG.=C2=A0

There is a = much, much larger universe of people who will make deployment and implement= ation decisions, with varying attention span and degrees of skill, and I th= ink they're best served with a clean start of an unambiguous version nu= mber. Just because it feels uncomfortable to us doesn't mean it will fe= el uncomfortable to the larger technical/enterprise community who don't= really *care* about the versioning scheme, they just need to make some dec= isions and move on.

-- Eric

On Fri, Nov 18, 2016 at 1:0= 7 PM, D. J. Bernstein <djb@cr.yp.to> wrote:
The largest number of users have the least amount of informat= ion, and
they see version numbers as part of various user interfaces. It's clear=
how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad)= but
4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is suppor= ted).

We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if = this type
of disaster happens to only 1% of site administrators, it strikes me as
more important for security than any of the arguments that have been
given for "TLS 1.3". So I would prefer "TLS 4".

Yes, sure, we can try to educate people that TLS>SSL (but then we're=
fighting against tons of TLS=3DSSL messaging), or educate them to use
server-testing tools (so that they can fix the problem afterwards---but
I wonder whether anyone has analyzed the damage caused by running SSLv3
for a little while before switching the same keys to a newer protocol),
and hope that this education fights against 3>1.3 more effectively than<= br> it fought against 3>1.2. But it's better to switch to a less error-p= rone
interface that doesn't require additional education in the first place.=

---Dan

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--
=
--001a113d58f4320a2205419ae45c-- From nobody Fri Nov 18 15:04:46 2016 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 16579129456 for ; Fri, 18 Nov 2016 15:04:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F0Y-Oe-XNQCe for ; Fri, 18 Nov 2016 15:04:43 -0800 (PST) Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (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 38E5F1293F3 for ; Fri, 18 Nov 2016 15:04:43 -0800 (PST) Received: by mail-ua0-x22d.google.com with SMTP id 20so183349106uak.0 for ; Fri, 18 Nov 2016 15:04:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=OofcWaegtQfu8No0nIkwOlb8ipRtE5Gm4zEBTDCEDGM=; b=CV4oXNkSOgIiterzGtXcrUjfy9aODQXulOKQg9uT/YAhVhGKyJGpR4TvXISAMJh3rr aX1ApGY1cHwR7/MGajeI+3Hi13yIOLi2k6ioW3Fwqx4xlMe3bL4yRSBbcNvbXghwiMBH 1g/35ALhCu7Fk8Z35efRLe9bsRptjzaRpBMV0pF5HDmn8Kg6wEJxzHanCvucH28iBpOR JfKPiJ5oltm+HF9N8JRFFJyotKdVqR9X2L3rDlx/IH9V09bm/41bXHf11SFpi7Z3COhF YnVUIhbVDS+9U3o/gVw7e7oZN945uKU6jSYKlfd6pXhabM7h95fxmItrYag5TuwetEsh kjkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=OofcWaegtQfu8No0nIkwOlb8ipRtE5Gm4zEBTDCEDGM=; b=BMhQw0W0aCofez53DA9Zxefi4Efv95Ya8vRpjPGtNYLwiVIsAG8NUb0WrEzixsZGmt ZiWStOJ2aZU2BDchEYtbj6aUsIjKkyLWYB2jTRmXd3ddvwNxbobxGg8+fE+VltUbEWyX 2H0KFlV+P4DTNX1WQtd/uMm3QBQTJnpGdQcFazFP1OojVASSLZ2Go+ot9W8ZMMEfZ/3m N2XB3HDCnDBaGAMWIlL+dulPDnGN4kFjB+P/wpM0TaD9FuhmcMfvvMo/jJkf2Xfv1c0g /R/QY3YaRlYdrxSJaspxoSaU0tpsQAm1Ys8Fyd8/mT+UM2b1fgIiQKDf3RiVMcxtbCX3 PTJw== X-Gm-Message-State: AKaTC03PjYBvu8anxfmJj9TlP76rT1WWnvG46DAW47vzZ7qDBsv4vD9zwi9aZc3Wc2wN0iQJO2ALI0xOcWphvA== X-Received: by 10.176.64.196 with SMTP id i62mr1497383uad.70.1479510282034; Fri, 18 Nov 2016 15:04:42 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Fri, 18 Nov 2016 23:04:31 +0000 Message-ID: To: "" Content-Type: multipart/alternative; boundary=94eb2c122c2ecd64a205419b54fb Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 18 Nov 2016 23:04:45 -0000 --94eb2c122c2ecd64a205419b54fb Content-Type: text/plain; charset=UTF-8 If we decide to move to some numeral higher than 3 to avoid confusion, I recommend *TLS 4*, but urge people to tell the story of the name in a way that retains some sense of continuity and logic. Here's a framing that makes sense: *TLS 4 is the fourth version of TLS* This framing will tell a positive message of progression, rather than embody a condescending message such as "we gave it this name because people aren't able to understand that TLS 1.3 is newer than SSL 3". It will also immediately make sense to people who were exposed to the marketing around Windows 7. Without this framing, TLS 4 (or 4.0) will seem like a confusing choice. (for the record, I'm still for TLS 1.3) On Fri, Nov 18, 2016 at 11:13 AM Sean Turner wrote: At IETF 97, the chairs lead a discussion to resolve whether the WG should rebrand TLS1.3 to something else. Slides can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf . The consensus in the room was to leave it as is, i.e., TLS1.3, and to not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on the list so please let the list know your top choice between: - Leave it TLS 1.3 - Rebrand TLS 2.0 - Rebrand TLS 2 - Rebrand TLS 4 by 2 December 2016. Thanks, J&S _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --94eb2c122c2ecd64a205419b54fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If we decide to move to some numeral higher th= an 3 to avoid confusion, I recommend TLS 4, but = urge people to tell the story of the name in a way that retains some sense = of continuity and logic.

Here's a framing that makes sense:
TLS 4 is the fourth versi= on of TLS

This framing will tell a positive message of progression, rather= than embody a condescending message such as "we gave it this name bec= ause people aren't able to understand that TLS 1.3 is newer than SSL 3&= quot;. It will also immediately make sense to people who were exposed to th= e marketing around Windows 7.

Without this framing, TLS 4 (or 4.0) will seem like a confusing choice.
(for the record, I'm still for TLS 1.3)
=

On Fri, Nov 18, 2016 at 11:13 AM Sean Tur= ner <sean@sn3rd.com> wrote:
At IETF 97, the chairs lead a discussion to r= esolve whether the WG should rebrand TLS1.3 to something else.=C2=A0 Slides= can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tl= s-rebranding-aka-pr612-01.pdf.

The consensus in the room was to leave it as is, i.e., TLS1.3, and to not r= ebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this decisi= on on the list so please let the list know your top choice between:

- Leave it TLS 1.3
- Rebrand TLS 2.0
- Rebrand TLS 2
- Rebrand TLS 4

by 2 December 2016.

Thanks,
J&S
_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--94eb2c122c2ecd64a205419b54fb-- From nobody Fri Nov 18 18:24:56 2016 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 E44E112951B for ; Fri, 18 Nov 2016 18:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=umich.edu 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 HTPkFag-tM2Z for ; Fri, 18 Nov 2016 18:24:51 -0800 (PST) Received: from mail-oi0-x22b.google.com (mail-oi0-x22b.google.com [IPv6:2607:f8b0:4003:c06::22b]) (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 70D5A1294A9 for ; Fri, 18 Nov 2016 18:24:51 -0800 (PST) Received: by mail-oi0-x22b.google.com with SMTP id 128so108311748oih.0 for ; Fri, 18 Nov 2016 18:24:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=umich.edu; s=google-2016-06-03; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=m6G2MxEsX0E9GmuXMMmt3xAXU2axZLX3j2i05JW0XEY=; b=pUDJX0GwGacTJRElyy98kf29dv6/pVywXFtkwFrGS+N/6KrRCwX/bM8wlta9A7RXmo JjfQJ7lkz3GLojR6VnDHHfZ7iQPxDS0so7wlpw8/qHdJVluQlrsmPn8o3VkERfDnwWZw EpH+uiXOWMUiqlNrzXHs3PG2oe4uVda/ymZe3Dyf7DVcgw3r7RdcWfWKBTr58HtTslit 3nl0w0UfPWZk8W/m4XZi0Ae3lqEr9QlLZSB8+H5ja64TMWqeKBb4opW6ip2vUr82Gezn kdE6K1Kl2KUdsCl/egdvzoDwNtn8jMZil5nEzQtNpzSyCPtjGhTq91ynyt6vXtOX53rh eDDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=m6G2MxEsX0E9GmuXMMmt3xAXU2axZLX3j2i05JW0XEY=; b=CS9Dj+tVLrzNZuQWhlgqIGUrF6W3Fi0WkuzeWrMlozkbEKOENqwCludHkoKBV3JhP/ iUHIzinZZNwSEV37R2sQ349lJ4nJ7LRV232tvnwbHsZ5WAR6rfPKbDnpww9EhiwMI9+9 wCqrx+WFyVVV9mnybO5fQec86f1eGQ3cb/nv/1ebSML0rndxGaF/g3LA01zwyeYaOX7M PUa8khC/tZmN/4FD43cGJXMw9mpUqv6txE0PIcgMoOa/eKJGLnPCBs+iv1i6tnPWhY0Y WenMPl1eagtuxCN71gYS0tcblZP3y4PPjdME0JVoof3CWeoOs3qdM6R3o25kqR21aqXu wfGQ== X-Gm-Message-State: AKaTC01jGlsCxaC71dgTrLu4n+cSuq1Cbc/KkusxdqK2z6b6SgHdBTqN8iG7/a4ccfD2XLQS X-Received: by 10.202.86.134 with SMTP id k128mr1918170oib.212.1479522290238; Fri, 18 Nov 2016 18:24:50 -0800 (PST) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com. [209.85.218.45]) by smtp.gmail.com with ESMTPSA id g22sm493674oib.17.2016.11.18.18.24.48 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 18:24:49 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id b126so70865566oia.2 for ; Fri, 18 Nov 2016 18:24:48 -0800 (PST) X-Received: by 10.157.11.212 with SMTP id 78mr1839649oth.183.1479522288667; Fri, 18 Nov 2016 18:24:48 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: David Adrian Date: Sat, 19 Nov 2016 02:24:37 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Nick Sullivan , "" Content-Type: multipart/alternative; boundary=001a113ec826742c2005419e2032 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 02:24:54 -0000 --001a113ec826742c2005419e2032 Content-Type: text/plain; charset=UTF-8 I recognize I don't participate on this list very often, but I also agree with TLS 4.0 and Dan's argument. I teach an undergraduate security course at Michigan; students have enough trouble keeping track of SSL vs TLS versions as it is. Jumping to 4.0 allows us to end this versioning debacle now. On Fri, Nov 18, 2016 at 6:04 PM Nick Sullivan wrote: > If we decide to move to some numeral higher than 3 to avoid confusion, I > recommend *TLS 4*, but urge people to tell the story of the name in a way > that retains some sense of continuity and logic. > > Here's a framing that makes sense: > > *TLS 4 is the fourth version of TLS* > This framing will tell a positive message of progression, rather than > embody a condescending message such as "we gave it this name because people > aren't able to understand that TLS 1.3 is newer than SSL 3". It will also > immediately make sense to people who were exposed to the marketing around > Windows 7. > > Without this framing, TLS 4 (or 4.0) will seem like a confusing choice. > > (for the record, I'm still for TLS 1.3) > > On Fri, Nov 18, 2016 at 11:13 AM Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf > . > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. > > Thanks, > J&S > _______________________________________________ > 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 > --001a113ec826742c2005419e2032 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I recognize I don't participate on this list very ofte= n, but I also agree with TLS 4.0 and Dan's argument. I teach an undergr= aduate security course at Michigan; students have enough trouble keeping tr= ack of SSL vs TLS versions as it is. Jumping to 4.0 allows us to end this v= ersioning debacle now.

O= n Fri, Nov 18, 2016 at 6:04 PM Nick Sullivan <nicholas.sullivan@gmail.com> wrote:
If we decide to move to some numeral higher than 3 to avoid confusion, = I recommend TLS 4, but urge people to tell the s= tory of the name in a way that retains some sense of continuity and logic.<= br class=3D"gmail_msg">

Here's a framing that makes sense:
TLS 4 is the fourth version of TLS

This framing w= ill tell a positive message of progression, rather than embody a condescend= ing message such as "we gave it this name because people aren't ab= le to understand that TLS 1.3 is newer than SSL 3". It will also immed= iately make sense to people who were exposed to the marketing around Window= s 7.

Without this framing, T= LS 4 (or 4.0) will seem like a confusing choice.
(for the record, I'= m still for TLS 1.3)
<= /div>

On Fri, Nov 18, 2016 at= 11:13 AM Sean Turner <sean@sn3rd.com> wrote:
At IETF 97, the chairs lead= a discussion to resolve whether the WG should rebrand TLS1.3 to something = else.=C2=A0 Slides can be found @ https://www.ietf.org/proceedings/97/s= lides/slides-97-tls-rebranding-aka-pr612-01.pdf.

The consensus in the room was to leave it as is, i.e., TLS1.3, and to not r= ebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this decisi= on on the list so please let the list know your top choice between:

- Leave it TLS 1.3
- Rebrand TLS 2.0
- Rebrand TLS 2
- Rebrand TLS 4

by 2 December 2016.

Thanks,
J&S
_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a113ec826742c2005419e2032-- From nobody Fri Nov 18 18:37:53 2016 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 A3E07129619 for ; Fri, 18 Nov 2016 18:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Xj6yXGHIps3d for ; Fri, 18 Nov 2016 18:37:51 -0800 (PST) Received: from mail-wj0-x22a.google.com (mail-wj0-x22a.google.com [IPv6:2a00:1450:400c:c01::22a]) (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 7882C129607 for ; Fri, 18 Nov 2016 18:31:00 -0800 (PST) Received: by mail-wj0-x22a.google.com with SMTP id v7so3758831wjy.2 for ; Fri, 18 Nov 2016 18:30:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=g522h9B+aNTHfTFJ/A/VgiYBA9ENbVdMjidnrIP4SvQ=; b=i9CkfeYCN7ZB6xp4JG2/9PPjB4X6sXwqsbDNlimSbME6e+pYo2edH1rKBp4PIePjVp YegDztxLT0je7HI9wBwRTVnV1f7PGrqf23KNOPpt0DhHXxiNjEUBQCDWXSDMyz2fa5DM Bs6cFaw/aq0vIfJL/DXkWMbAn0ClmzQ1kX2072Le18LOunJmL9GvzaYADrwjF4BdEB8f adGPy3ZfPMEmrIlSsjP7K1LYCr/L0mN0+ydfpztbFOWRZKCJ5vC+BR0pJohCq3kQICpc FNzZCS9X/lx8BfnoTErGT/mjeP7tPabPqT4ED+JXVW8Ae8jFdWOQiz6sTVUC4fZbQcVa k71w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=g522h9B+aNTHfTFJ/A/VgiYBA9ENbVdMjidnrIP4SvQ=; b=aeM33TzCI1DX7fRGJPZD0B/Qm7mcGGp8fn9/G28Qw2VPhhceB39l3qxFZjMBcDACfA T2iDNsHkGTlT7vO7+LdY2NMlp83xJjnLqh8uvGd+o35Wd8anvIpN1j84hhQhNxc0EwEy Y866sIfgaBjZNpt4W2ihtFDN7iUUA1PkhzgmkbTpiGTskP1A4y3V80RxUcRzQOr3kIab Uor6fHbNi0MS57JCE5BjLV4ZaEdeumSkJ+VAGYPASDP0sjA/IQMD5HXLpFVDn7ykrP/4 gqczKy2PakhtwjJMR1z28EwMRBcX2PtSO+snygB2f9rtyPdF2oo1l3yFxKhxV+yxw6q5 4TSg== X-Gm-Message-State: AKaTC00ngHA8fEa1PdbL6hjjzbVSAJA6Z1gMxPaBg8H08Hk7ecjLVm2BIp0dTx64VsNFjZNZwFv7AsBpTbGdkA== X-Received: by 10.194.116.66 with SMTP id ju2mr1567534wjb.223.1479522658389; Fri, 18 Nov 2016 18:30:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.32.1 with HTTP; Fri, 18 Nov 2016 18:30:57 -0800 (PST) In-Reply-To: References: <20161118180737.16475.qmail@cr.yp.to> From: Kazuho Oku Date: Sat, 19 Nov 2016 11:30:57 +0900 Message-ID: To: Eric Mill Content-Type: multipart/alternative; boundary=001a1130d2667d917505419e36a5 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 02:37:52 -0000 --001a1130d2667d917505419e36a5 Content-Type: text/plain; charset=UTF-8 2016-11-19 7:32 GMT+09:00 Eric Mill : > It seems like TLS 2 and TLS 2.0 have very little support, so it's really > just deciding between: > > TLS 1.3 > TLS 4 (or maybe 4.0) > > I oppose to going to TLS 4, due to the following reasons: * it might give people false notion that SSL 2.0, 3.0 is superior to TLS 1.0-1.2 * if name the new protocol TLS 1.3, 2.0, or 2, then there would be no confusion once SSL goes away. However, if we name the new version TLS 4, then people would (for upcoming tens of years) continue to ask where TLS 2 and TLS 3. > I'll just amplify Rich's and djb's points by noting that the cost of > switching away from TLS 1.3 really only affects a very small number of > people -- really just the people in and around this WG. > > There is a much, much larger universe of people who will make deployment > and implementation decisions, with varying attention span and degrees of > skill, and I think they're best served with a clean start of an unambiguous > version number. Just because it feels uncomfortable to us doesn't mean it > will feel uncomfortable to the larger technical/enterprise community who > don't really *care* about the versioning scheme, they just need to make > some decisions and move on. > > -- Eric > > On Fri, Nov 18, 2016 at 1:07 PM, D. J. Bernstein wrote: > >> The largest number of users have the least amount of information, and >> they see version numbers as part of various user interfaces. It's clear >> how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad) but >> 4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is supported). >> >> We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if this type >> of disaster happens to only 1% of site administrators, it strikes me as >> more important for security than any of the arguments that have been >> given for "TLS 1.3". So I would prefer "TLS 4". >> >> Yes, sure, we can try to educate people that TLS>SSL (but then we're >> fighting against tons of TLS=SSL messaging), or educate them to use >> server-testing tools (so that they can fix the problem afterwards---but >> I wonder whether anyone has analyzed the damage caused by running SSLv3 >> for a little while before switching the same keys to a newer protocol), >> and hope that this education fights against 3>1.3 more effectively than >> it fought against 3>1.2. But it's better to switch to a less error-prone >> interface that doesn't require additional education in the first place. >> >> ---Dan >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > > -- > konklone.com | @konklone > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > -- Kazuho Oku --001a1130d2667d917505419e36a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


2016-11-19 7:32 GMT+09:00 Eric Mill <eric@konklone.com>:=
It seems like TLS 2 and= TLS 2.0 have very little support, so it's really just deciding between= :

TLS 1.3
TLS 4 (or maybe 4.0)

<= /div>

I oppose to going to TLS 4, due= to the following reasons:

* it might give people = false notion that =C2=A0SSL 2.0, 3.0 is superior to TLS 1.0-1.2
*= if name the new protocol TLS 1.3, 2.0, or 2, then there would be no confus= ion once SSL goes away. However, if we name the new version TLS 4, then peo= ple would (for upcoming tens of years) continue to ask where TLS 2 and TLS = 3.
=C2=A0
I'll just amplify Rich's and djb's points by noti= ng that the cost of switching away from TLS 1.3 really only affects a very = small number of people -- really just the people in and around this WG.=C2= =A0

There is a much, much larger universe of peopl= e who will make deployment and implementation decisions, with varying atten= tion span and degrees of skill, and I think they're best served with a = clean start of an unambiguous version number. Just because it feels uncomfo= rtable to us doesn't mean it will feel uncomfortable to the larger tech= nical/enterprise community who don't really *care* about the versioning= scheme, they just need to make some decisions and move on.

<= /div>
-- Eric

On Fri, Nov 18, 2016 at 1:07 PM, D. J. B= ernstein <djb@cr.yp.to> wrote:
= The largest number of users have the least amount of information, and
they see version numbers as part of various user interfaces. It's clear=
how they will be inclined to guess 3>1.3>1.2>1.1>1.0 (very bad)= but
4>3>1.2>1.1>1.0 (eliminating the problem as soon as 4 is suppor= ted).

We've all heard anecdotes of 3>1.2>1.1>1.0 disasters. Even if = this type
of disaster happens to only 1% of site administrators, it strikes me as
more important for security than any of the arguments that have been
given for "TLS 1.3". So I would prefer "TLS 4".

Yes, sure, we can try to educate people that TLS>SSL (but then we're=
fighting against tons of TLS=3DSSL messaging), or educate them to use
server-testing tools (so that they can fix the problem afterwards---but
I wonder whether anyone has analyzed the damage caused by running SSLv3
for a little while before switching the same keys to a newer protocol),
and hope that this education fights against 3>1.3 more effectively than<= br> it fought against 3>1.2. But it's better to switch to a less error-p= rone
interface that doesn't require additional education in the first place.=

---Dan

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



<= /div>--

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls




--
Kazuho Oku
--001a1130d2667d917505419e36a5-- From nobody Fri Nov 18 18:41:11 2016 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 9593E12951B for ; Fri, 18 Nov 2016 18:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 tKh_G9DgEHRz for ; Fri, 18 Nov 2016 18:41:07 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF3B8129439 for ; Fri, 18 Nov 2016 18:41:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1479523266; x=1511059266; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=NTi/bEP5QLehHvw9ZS3x8n5YcSqsfKKFYOMVMFgEJLQ=; b=rlr+Xv3olxxgQaIeVGlQns8IhNCyU4dzr7amxtdcg6cBP4ex0rETd/gO DVFRDO1VxXZZIioZ51jhK1YaG48tlYdI6VKq150Es77k9MfbjKf53J9tc AQNGgjzupjDhX16eDCtjDBiyadcKuZzT1zwaMxY/RDcrr6NyPQ7nDDP1C GOHDgUaxmjHPTOqL9Au/noGxl8MiBJirQaqmhwPt6oTtMH6tREAOcA8sb cxATPQ1ucgNYy7y7oxvJyjBc5hl0X78Z8Y9VGeusBuhzj1EVOGBgpXTQW t/n4lN1xmasd8EsZTqY35Z62aCyhwZX1bkTFffec4SrOG9CG5caMegGuQ A==; X-IronPort-AV: E=Sophos;i="5.31,513,1473076800"; d="scan'208";a="115889384" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.4 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-tdc-c.UoA.auckland.ac.nz) ([10.6.3.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Nov 2016 15:41:05 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-c.UoA.auckland.ac.nz (10.6.3.24) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 19 Nov 2016 15:41:04 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 19 Nov 2016 15:41:04 +1300 From: Peter Gutmann To: Ilari Liusvaara Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFcD667DaatoU6RNleDGo1T66Ddz30AgADmRXP//1ILgIABkg4f Date: Sat, 19 Nov 2016 02:41:04 +0000 Message-ID: <1479523253827.80996@cs.auckland.ac.nz> References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz>, <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 02:41:10 -0000 Replying to several messages at once to save space:=0A= =0A= Ilari Liusvaara:=0A= =0A= >One can downnegotiate TLS 1.3 to TLS 1.2.=0A= =0A= Ah, you're obviously a fan of Steve Wozniak humour. When someone asked him= =0A= whether it was possible to upgrade from an Apple II+ to an Apple IIe, he=0A= similarly said "yes, you unplug the power cable from the II+, throw it away= ,=0A= and plug the IIe into the newly-vacated power cable".=0A= =0A= Christian Huitema:=0A= =0A= >I prefer TLS 1.3, because is signals continuity with the ongoing TLS=0A= >deployment efforts.=0A= =0A= Maybe it's just me, but wouldn't the fact that they're both called TLS sort= of=0A= indicate that there's continuity there?=0A= =0A= Dave Kern:=0A= =0A= >I'm in favor of TLS 4, and ignoring the minor version number (in the frien= dly=0A= >text string, not the protocol field) moving forward.=0A= =0A= That's actually a good point, "TLS 4" provides a single, clean number for p= eople=0A= to remember. Even a CTO or auditor should be able to get that one right wi= thout=0A= having to look up a table in a book to see that 1.3 > v3.=0A= =0A= Peter.= From nobody Fri Nov 18 19:01:45 2016 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 182261295C7 for ; Fri, 18 Nov 2016 19:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 cWToAh5fTWDP for ; Fri, 18 Nov 2016 19:01:43 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9C91295AC for ; Fri, 18 Nov 2016 19:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1479524502; x=1511060502; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=edqoSs7uMuFvgjYraM3xpur5ef6OS9AE3lzZBQCP6F0=; b=j0ybJP+H+7YOhzp8gF1n3Y9TAZBnB7IYMllAdnP4M/MA6ElBTzV5vFPp AuIvWMfUzc3kB+oE8VtOPbxilxERbXYNjIdhET1UlHbiXw5dHT6xtkc3Z Boh7DXr66REXyZDyELCsNYIxDlL+5ro+OmZgb6Nub622/ac543X1SKuZP R0GHaJe0idcVTJJNQahNn+VJrjG8q8NUSR9UtPpFnC1LqndmDliPPtZBp uQOdx0315kV7gJ8nYaEVEg9/TXp5nJLmGau6W/Ov4ANeZJizPrzrpgNEp v90fZ1t+K1Yk4OVt96ZK1BwFxGI9eKhMUBcNt6qRoUi10/wwwzYy/gvH7 A==; X-IronPort-AV: E=Sophos;i="5.31,513,1473076800"; d="scan'208";a="115890428" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.2 - Outgoing - Outgoing Received: from uxcn13-ogg-a.uoa.auckland.ac.nz ([10.6.2.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 19 Nov 2016 16:01:41 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-a.UoA.auckland.ac.nz (10.6.2.2) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 19 Nov 2016 16:01:39 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sat, 19 Nov 2016 16:01:39 +1300 From: Peter Gutmann To: Vlad Krasnov , "D. J. Bernstein" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFcD667DaatoU6RNleDGo1T66DeMNiAgAAWzYCAAVf3+w== Date: Sat, 19 Nov 2016 03:01:38 +0000 Message-ID: <1479524488503.69936@cs.auckland.ac.nz> References: <20161118180737.16475.qmail@cr.yp.to>, <555F1FCF-CB73-48D4-AC7C-A255EF3ACE2C@cloudflare.com> In-Reply-To: <555F1FCF-CB73-48D4-AC7C-A255EF3ACE2C@cloudflare.com> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 03:01:44 -0000 Vlad Krasnov writes:=0A= =0A= >Second: I don=92t think that the changes between TLS 1.3 and TLS 1.2 are= =0A= >considered a major: just look at the difference between HTTP/2 and HTTP/1 = -=0A= >those are completely different protocols.=0A= =0A= So are TLS 1.x and "1.3". It'd be interesting to hear from other implement= ers=0A= on this, but my secure-tunnel code consists of a high-level framework that= =0A= handles things at an abstract level, client hello, server hello, keyex, key= ex-=0A= auth, finished, and subsequent stuff, and that's the same for both TLS and = SSH=0A= (I use TLS names for consistency, but SSH does the same things under its ow= n=0A= names). The bit-bagging for the two is obviously quite different, but the= =0A= high-level handling is taken from the same code.=0A= =0A= For "1.3" I looked at what it'd take to bolt it onto the side of the other = 1.x=0A= code and it'd end up as this weird hermaphrodite mixture with huge amounts = of=0A= effort devoted to trying to track whether it's meant to be acting as 1.x or= =0A= "1.3", with the accompanying opportunity for problems if I miss something a= nd=0A= drop from 1.x to "1.3" or the other way round. The easiest way to implemen= t=0A= it is as a new protocol, trying to pretend that 1.x and "1.3" are the same= =0A= thing just leads to an implementation nightmare when you have to keep the t= wo=0A= distinct.=0A= =0A= So at least from this implementation's point of view, they're different=0A= protocols.=0A= =0A= Peter.= From BATV+fc626df8638c750ac231+4836+infradead.org+dwmw2@bombadil.srs.infradead.org Fri Nov 18 19:01:13 2016 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 09E1B1295C7 for ; Fri, 18 Nov 2016 19:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 GPm9_g2rHVTy for ; Fri, 18 Nov 2016 19:01:10 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 82E2D1295AC for ; Fri, 18 Nov 2016 19:01:10 -0800 (PST) Received: from [67.132.130.174] (helo=shinybook.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1c7vtq-0008Nk-38; Sat, 19 Nov 2016 03:01:06 +0000 Message-ID: <1479524464.4382.1.camel@infradead.org> From: David Woodhouse To: Vlad Krasnov , "Salz, Rich" Date: Fri, 18 Nov 2016 19:01:04 -0800 In-Reply-To: <748B7799-7B8B-42A6-AB2C-C34971367B20@cloudflare.com> References: <20161118180737.16475.qmail@cr.yp.to> <555F1FCF-CB73-48D4-AC7C-A255EF3ACE2C@cloudflare.com> <51691c7b6a314319988719c0bb8bf456@usma1ex-dag1mb1.msg.corp.akamai.com> <748B7799-7B8B-42A6-AB2C-C34971367B20@cloudflare.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-vvJXV2g9GYl/qpy4qhRz" X-Mailer: Evolution 3.22.1 (3.22.1-2.fc25) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Cc: "D. J. Bernstein" , "tls@ietf.org" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 03:08:32 -0000 --=-vvJXV2g9GYl/qpy4qhRz Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, 2016-11-18 at 13:19 -0800, Vlad Krasnov wrote: > > Well, for example, your website has twice as many mentions of SSL > > as TLS.=C2=A0=C2=A0Why?=C2=A0=C2=A0Why don't you have a product called = "Universal TLS"? > > The ratio is the same for letsencrypto.org. TLS 1.0 had already > > existed for more then a decade before either place existed.=C2=A0=C2=A0= BTW, > > at google, it's 20:1, and that's just google, not the web.=C2=A0=C2=A0(= Counts > > were done in the obvious dumb way "site:letsencrypt.org tls" and > > then with "ssl" and noting the summary stats at the top of the > > return results.)=C2=A0 > >=20 > > People are confused because we treat them as the same thing.=C2=A0 >=20 > Well, if the result of the confusion would be people *disabling* TLS > 1.* in favor of SSL 3.0, they would discover very quickly what is > TLS, and why no major browser works for them. We already have a bunch of confusion around "SSL" vs. "TLS". Many mail clients seems to allow you to configure SMTP/IMAP servers to be accessed over "SSL", which means TLS, or "TLS", which means it connects in the clear and then negotiates an upgrade with STARTTLS. --=20 dwmw2 --=-vvJXV2g9GYl/qpy4qhRz Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYxMTE5MDMwMTA1WjAvBgkqhkiG9w0BCQQxIgQg+eApgTDBZzkYr+NebB3bFGIzNh352bdDCPIX iUapFP4wgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAFJS rwFcmrLVlNpJbYZGCJZNKL1qEoCsbd1GBGzX8oG29Mrf8IhJv78YqU7yrnAL0nds8oHyyvKJ31N5 t2YEVt8x6IcvsAGsrJxuGXzT86KUejmV6MhH8cdsSGo8OwRln4+1miJyqa6+5fE2jCkb9Bbx0NB8 hJXnw0Qeg8+hcJvyaF9TpOZNfdo4EpnhPuUe20xh7K/sOB2Q9WRlhKjhQ5QjlTS2Ho4vIZJLcrIL UFcGM2oI1jRokgJANDaC11hUS5AK5NKbZFc6vmu+HvP1oMG3XMx53lAerpg5D9I2WG/SttExSwGf /YBMoaI8JXIVHDFGrSdfD+V5QchDaoqtBbqLP/ceMSu/Vb+tGbpuLXtpFEh2AKAaQ5qC0EEg2QNr /ddVUt0g37DP+O/JhBHDAyPWF7H4ADBR/5BHt5RSEzMCXe63incYdn12K3qEzJ5LWSIAU/EvWUGD +wy+sdBuyZONXtsCrEuMxryuS9N8XYyTlT8K0LbzRYYGSO0O3BspSprp1sEcSuBK0Tf8TQRfMRgD oRggKifxnDWg9lQw4E2aSnPp+NZGd4ptp9py+Sokm3BOTtEMQJNyzOYUcQfl5pWjALI8wflglLME rl6Mo533TaFEOwzA7TrBCE0hojVoEVC+lKfjUlxohTUnP2wvvdwKneQSp9FgR2ntnNUye6qjAAAA AAAA --=-vvJXV2g9GYl/qpy4qhRz-- From nobody Fri Nov 18 19:22:57 2016 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 13D1B1294FD for ; Fri, 18 Nov 2016 19:22:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nomountain-net.20150623.gappssmtp.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 XrQYB-TPt2ot for ; Fri, 18 Nov 2016 19:22:54 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (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 8B6FA1293FD for ; Fri, 18 Nov 2016 19:22:54 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id p66so109121842pga.2 for ; Fri, 18 Nov 2016 19:22:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nomountain-net.20150623.gappssmtp.com; s=20150623; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=5EDVyXNLwZk6KoEIs4lr+UKjsIpZT329Ew4GRD+oAlY=; b=crS/W1jkSexGRdQ8Yg7rc40fxGCDKfX6TQewS/L3Qu45xyRN+CIhnDlVp4/ymJkSfu M+D738BKUPcehs9YrewCJMHORzFDNcmJ53a/bxaQQf19GUEwHNlgag19nncnZPsq/LpH GcJiZf9qj25zquMWk5yqJNNP7YDaVvKP85CshLmRMVriRz/iwSfhsfUHTREANOiC5XSx w+r3vLWuq2YRDVC7eksm+oZ2c5bVidoKNAP6k6c9Nd3Mpp4QQlxwmTVEXLGHa0m9LlSw Wy5RafNYv8XMsMeCEsI/U3xAufz5pj9relbEfmaEv5WmS/6XUpF/3LoWC2rsopGh5A1o 695w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=5EDVyXNLwZk6KoEIs4lr+UKjsIpZT329Ew4GRD+oAlY=; b=MrynnGLIljzbzC2XDPXURQxpoz2ld+EXB+d5UOsPGsqUl3NZefA4oY10xhPM2KpkHO ku8TGH6yRMFKawf4t0IkVxIHXDIa3cDA4xuhcki6+tIEUK9Qwwiv9WHK5hAIgOOcXM3S QehsQqNnjJM5ePyPZQvSy5Z6LQufRviaGfoJQUWxk/yGQs+KKMMSrVeLZY5nA701EtKS cOWR+LLE/OLBnxyXMeGH+6nzIfdgqvrfZKFhWcrlpprZZHec5YU2Ez7aSwet+lA4Npfz FTQPtMtYYsH0Xgee9W6A2mPHQ6X607hmP6I7fB6S8mDTvBCJpkfouDltFNfDdcxQLAvr jvGQ== X-Gm-Message-State: AKaTC03mdNe4on1acs1xIn/LcnmTWak8xUcKvx5gB44tBSo65TonGKe5nItC0qhKqgL5RQ== X-Received: by 10.99.218.85 with SMTP id l21mr6362635pgj.102.1479525773792; Fri, 18 Nov 2016 19:22:53 -0800 (PST) Received: from Melindas-MacBook-Pro.local (ip-64-134-140-2.public.wayport.net. [64.134.140.2]) by smtp.gmail.com with ESMTPSA id a11sm537729pfe.96.2016.11.18.19.22.50 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 19:22:53 -0800 (PST) To: Martin Thomson , Peter Gutmann References: <1479463783973.10653@cs.auckland.ac.nz> From: Melinda Shore Message-ID: Date: Fri, 18 Nov 2016 19:22:49 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pD4cRTQb5MqjIIhUout2r4HDCKObCjuBg" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 03:22:56 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pD4cRTQb5MqjIIhUout2r4HDCKObCjuBg Content-Type: multipart/mixed; boundary="qigmhoj5TxTT5LDDI8kLGO3tGO4uMX91N"; protected-headers="v1" From: Melinda Shore To: Martin Thomson , Peter Gutmann Cc: tls@ietf.org Message-ID: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* References: <1479463783973.10653@cs.auckland.ac.nz> In-Reply-To: --qigmhoj5TxTT5LDDI8kLGO3tGO4uMX91N Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 11/18/16 2:18 PM, Martin Thomson wrote: > In the end, it's just a label. Well, there are some semantics to it - I think a label can be more than just a label. It occurred to me that it's guaranteed that if it's rebranded as TLS 4 we'll have people showing up with internet drafts proposing TLS 2 and 3, much like we've got occasional proposals for IPv5 (or other various versions). That said, I figure that's only a problem to the extent that calories are burned in response to these proposals, and what will matter is whether or not it's likely to lead systems administrators and those bringing up services to make bad configuration and deployment decisions. Melinda --qigmhoj5TxTT5LDDI8kLGO3tGO4uMX91N-- --pD4cRTQb5MqjIIhUout2r4HDCKObCjuBg Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJYL8WKAAoJELiGRpM6HoEutWIP/3m0qIeezgHiDrZyT85bQXU4 5wzVtlcvpIQSpUDA2H77QuzrwJWQ9Jfcuh8OsWbPqBEJZ5TOr6eXW2d9rboV48/+ 6qJxZLNzgRT2Z2vsq5zDRv0pgqQzL/VbkQiW1HrCAq29Otu4gE/EPUv3isobUj1W lbtEV9VMP+s/YmdRGv0uhsr6JZXav6LmB3T6SL2r21UNeQYKo1fdptYvjaIXHWfC PB1EK4adiV/Ujchhr0f6PnRjLfg4Nq6ViUuVefslD59gh7+0mgCco12WnVCAsyru 0J8dZkP2tRaTtxwFxcu66SEUuhgt2y8rJy1Z2PgWVKLeVuEvGrdv3U3m0t83iVic yIS6Ddo1HmSxuvu4TKnFSnArPLw5+WKLa2TN+lApAF0LPXLnjKYSV33OU63CVAUd KuBSWhxnCFNAIwKYk+YUoB+IKR4TPQ07rp80EZjWyrnJxebZ5Bj8bEnG1zceyjRH 6CRbQXqp16KVSYWOZ3Z5AEp5AEUza/xJpeCRl/meHS0t0IXR66TvvvlqT35JMeJw KoYvXM0PyZtgHoSJ+aIAHbsHgm8sOrWiztPiNLxGSGlXdrqw+tGjE2Hkl9oHEb3M cHxGFOB2yalz7j7S+bW/M6LRqyA7LtVqpxhRUC+QXJ+GCmaamr1FbFbRj78YJyC1 doqw4gsruPUn1AdNgibn =/UYb -----END PGP SIGNATURE----- --pD4cRTQb5MqjIIhUout2r4HDCKObCjuBg-- From nobody Fri Nov 18 20:37:07 2016 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 00F7612961E for ; Fri, 18 Nov 2016 20:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.109 X-Spam-Level: X-Spam-Status: No, score=-1.109 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 E4IKkq3rSrD1 for ; Fri, 18 Nov 2016 20:37:04 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 DAEAE129592 for ; Fri, 18 Nov 2016 20:37:03 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id x190so289127394qkb.0 for ; Fri, 18 Nov 2016 20:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:subject:message-id:date:to :mime-version; bh=YHHceZz63RqMnQq5657tPzn26wCza3oQ8R9pY54HuT4=; b=YJKGfdjcyEokpEJOwCNWJ3yYtFjRKY4/ISbLiT1S9cm7C9XvFadhEl5vex8u59DZGr YNxBE+PLLwP0o/US1VfUFC8N2LCqhjPnScuYcN65Ceb+Lty9aNeO0lwOK/dHzI6Q6Xk/ S/sqHUuKmIGHu3pHB0pcAhgGphBn1uS/CXBXk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:subject :message-id:date:to:mime-version; bh=YHHceZz63RqMnQq5657tPzn26wCza3oQ8R9pY54HuT4=; b=itWRsjoln9Bi64D/hup39kXftnREXj6dhp4/XAGbYNgyUrzF0+LcgGOCZT8LG0RB/d v2lZZTVCxf2J0aNY57pURwN4iaAPax8R/L9EskqxBIsp1eaiUyN2XLJnaE0elsyaYzMY 6gebvFC530/qBkGpad9sZlEKZgKq0yC0ZT3wVP2nJuUiJi3Rjeyxr/8oYiVu2avMJY9n twK3Kr9ORudXbz1A6DUSBBmU9ea8KfBa5RbizSSxpEsVNLYztTzsVMQxyY4n6Tu9MOVT zDxtBhHOyTGJol1nG98kdUkrTkz9TGRoQvHATbUWkLCkmm/fg/wf+87dnmIyWNwQFLZt xYPA== X-Gm-Message-State: AKaTC01sS/mYBKRU/oTtjgX42WT59kfx+PJSa9OFogE4yCtXdsyfIrfYMZTRry3x4j4buQ== X-Received: by 10.233.237.147 with SMTP id c141mr3513724qkg.175.1479530222797; Fri, 18 Nov 2016 20:37:02 -0800 (PST) Received: from [172.16.0.92] ([96.231.230.70]) by smtp.gmail.com with ESMTPSA id x4sm5699896qtc.42.2016.11.18.20.37.01 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 18 Nov 2016 20:37:02 -0800 (PST) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> Date: Fri, 18 Nov 2016 15:55:39 -0800 To: "" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 04:37:06 -0000 All, This is a working group last call for the =E2=80=9C4492bis to Standards = Track" draft available @ = http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/. Please = review the document and send your comments to the list by 9 December = 2016. =20 Note that we are particularly interesting in the issue Yoav raises in = the following message: https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk Thanks, J&S= From nobody Fri Nov 18 22:27:36 2016 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 7AB3812978B for ; Fri, 18 Nov 2016 22:27:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 KvjS4xX3h5wR for ; Fri, 18 Nov 2016 22:27:32 -0800 (PST) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 91FE812957E for ; Fri, 18 Nov 2016 22:27:32 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id ADBBE170A0; Sat, 19 Nov 2016 08:27:30 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id cv-fxCXmXXz7; Sat, 19 Nov 2016 08:27:30 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 630D02310; Sat, 19 Nov 2016 08:27:30 +0200 (EET) Date: Sat, 19 Nov 2016 08:27:25 +0200 From: Ilari Liusvaara To: Peter Gutmann Message-ID: <20161119062725.GA30600@LK-Perkele-V2.elisa-laajakaista.fi> References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz> <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> <1479523253827.80996@cs.auckland.ac.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <1479523253827.80996@cs.auckland.ac.nz> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 06:27:34 -0000 On Sat, Nov 19, 2016 at 02:41:04AM +0000, Peter Gutmann wrote: > Replying to several messages at once to save space: > > Ilari Liusvaara: > > >One can downnegotiate TLS 1.3 to TLS 1.2. > > Ah, you're obviously a fan of Steve Wozniak humour. When someone asked him > whether it was possible to upgrade from an Apple II+ to an Apple IIe, he > similarly said "yes, you unplug the power cable from the II+, throw it away, > and plug the IIe into the newly-vacated power cable". Nope, I was referring to the very technical property that if client sends a TLS 1.3 handshake, a TLS 1.2 server can still successfully interop, provoded that the client does TLS 1.2 too (which I think every TLS client known to support TLS 1.3 except Picotls does). The last major version bump, SSLv2->SSLv3, this was NOT true. SSLv2 server would barf upon receiving SSLv3 client hello (TLS 1.0 was clearly "SSL v3.1" internally). And folks could think that kind of downnegotiation wasn't the case given major version bump. Such would cause confusion much much worse than confusing the ordering of TLS and SSL versions. -Ilari From nobody Fri Nov 18 22:35:47 2016 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 69EB912957E for ; Fri, 18 Nov 2016 22:35:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] 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 SY0R_L2vZQjK for ; Fri, 18 Nov 2016 22:35:44 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 E8B7D12978C for ; Fri, 18 Nov 2016 22:35:43 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id q130so291886850qke.1 for ; Fri, 18 Nov 2016 22:35:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lSK4EsJIGiKa83ULefOv2K/h9ppjm75XBKueRQnMzsE=; b=Y6dQb8z13fIyaFTKV0svprxjEnEG7szP/6PQOj2lRH5oA6fA2+hqVUmcKKBsR2X6o8 xecUr8dR5S623XWaVC5V/R7GbPfiNTnvBk5DvkkCCUiB82m6QzgDEYLLGCx4LVI7g/oY 0HSDiCY7W+Zp4V+n5eYZTwYaZ7kJuTv3H6ANN7mP13AfijfknZls1ygTorp860VqJgTx +qDkGyxiFDJPue+h9NvyP6NSQuW8Wsr0CP4d5c34dw+w1OcDjBFxfjXQqU4XAnIuue58 9SNc0DLWdGS/fFJZIps5LQ5+7mAhfGhbIu0QbLJtgh/3qzBcm06/cdMcaiIiPV527Pjo BVew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lSK4EsJIGiKa83ULefOv2K/h9ppjm75XBKueRQnMzsE=; b=SKtYGb87ad+cEn/mFDVuJ95JMZY2FYlCBR+a8we9qrDas1Zjbw7sfCPbWuzB+q5Yym VQgojmRGWjhCW10A3HZSTo6M1hS3tpV98CxOVk4pbJ8RGGZpTim2wih+SP2znYgb+pHh M14PZcI0Ckr/w4GAIo9SWNoySPmUO/RGmWM/z45OETU8lTObHDc3E5sR0MJ1+XX91qFi oQmt7Je9SuP/PuJCwSLOgcwcPkfOHNjAcjV0yL265X03wVTcDbZLxw6C9VplIYJ4h03f JGJbIXuB3wPBxNpLGuq38IDQ2enN6NLdVGlxzjnb7FDXFgb5DlNlxapvF9+QeqIFSw9J kiCw== X-Gm-Message-State: AKaTC02JgH76KkhCjanbrHvBxhRN/YhqmwlIEy0czFr+WjUCuIJ8M3CYGHSnYhNiskGYM5cIUQiTuZkcqMGX5tFi X-Received: by 10.55.86.70 with SMTP id k67mr4583548qkb.280.1479537342842; Fri, 18 Nov 2016 22:35:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.157.11 with HTTP; Fri, 18 Nov 2016 22:35:41 -0800 (PST) In-Reply-To: References: <20161118180737.16475.qmail@cr.yp.to> From: Victor Vasiliev Date: Sat, 19 Nov 2016 01:35:41 -0500 Message-ID: To: Kazuho Oku Content-Type: multipart/alternative; boundary=001a114e718ec0f0bd0541a1a199 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 06:35:45 -0000 --001a114e718ec0f0bd0541a1a199 Content-Type: text/plain; charset=UTF-8 On Fri, Nov 18, 2016 at 9:30 PM, Kazuho Oku wrote: > I oppose to going to TLS 4, due to the following reasons: > > * it might give people false notion that SSL 2.0, 3.0 is superior to TLS > 1.0-1.2 > * if name the new protocol TLS 1.3, 2.0, or 2, then there would be no > confusion once SSL goes away. However, if we name the new version TLS 4, > then people would (for upcoming tens of years) continue to ask where TLS 2 > and TLS 3. > > I very much agree with those points. TLS 4 is a confusing name that, as far as I can tell, cannot actually make things better. Right now we have: SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 1.3 (1) Now, some people may get confused by this because of the "SSL is TLS" idea, but once you learn that in reality "SSL is a thing that was before TLS", it does make sense and seem fairly straightforward (a series of numbers under one name, followed by another series of numbers under the new name). With TLS 4, we have: SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 4 (2) This does has a nice property of indicating that TLS 4 is clearly the latest version (as long as you know that SSL came before TLS), but omission of TLS 2 and TLS 3 will leave people confused, and most likely lead them to conclude that what happened is TLS was renamed to SSL and then back again, so that TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> SSL 2 -> SSL 3 -> TLS 4. (3) But this is not even the worst of the problems. The real problem is that we can't actually rename TLS 1.3, because at the end we will merely create a new name for it. It has already been TLS 1.3 for a few years, it has been discussed in the tech community as TLS 1.3, researchers have published papers about TLS 1.3, there's probably already the marketing material with TLS 1.3 out there. The code that refers to it as TLS 1.3 will probably end up being referring to it as 1.3 for approximately forever, even if all the implementers had been enthusiastic about renaming it, because refactoring is high-cost and low-priority, and may not be even possible if you've already exposed it via the ABI. The old name will never die, and it will be a burden to anyone in this community, making confusing versioning scheme even more confusing. It will probably leak outside of it too, and instead of (2), we will end up getting SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 1.3 = TLS 4 (4) which seems strictly more confusing than (1) in any way. tl;dr: the only way to minimze confusion at this point is to not change anything. --001a114e718ec0f0bd0541a1a199 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On F= ri, Nov 18, 2016 at 9:30 PM, Kazuho Oku <kazuhooku@gmail.com> wrote:
I oppose t= o going to TLS 4, due to the following reasons:

* = it might give people false notion that =C2=A0SSL 2.0, 3.0 is superior to TL= S 1.0-1.2
* if name the new protocol TLS 1.3, 2.0, or 2, then the= re would be no confusion once SSL goes away. However, if we name the new ve= rsion TLS 4, then people would (for upcoming tens of years) continue to ask= where TLS 2 and TLS 3.


I very much ag= ree with those points.

TLS 4 is a confusing n= ame that, as far as I can tell, cannot actually make
things bette= r.=C2=A0 Right now we have:

=C2=A0 =C2=A0 SSL 2 -&= gt; SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 1.3 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(1)

Now, = some people may get confused by this because of the "SSL is TLS" = idea, but
once you learn that in reality "SSL is a thing tha= t was before TLS", it does
make sense and seem fairly straig= htforward (a series of numbers under one name,
followed by anothe= r series of numbers under the new name).

With TLS = 4, we have:

=C2=A0 =C2=A0 SSL 2 -> SSL 3 -> = TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 4 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0(2)

This does has a ni= ce property of indicating that TLS 4 is clearly the latest
versio= n (as long as you know that SSL came before TLS), but omission of TLS 2
and TLS 3 will leave people confused, and most likely lead them to c= onclude
that what happened is TLS was renamed to SSL and then bac= k again, so that

=C2=A0 =C2=A0 TLS 1.0 -> TLS 1= .1 -> TLS 1.2 -> SSL 2 -> SSL 3 -> TLS 4. =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 (3)

But this is not ev= en the worst of the problems.

The real problem is = that we can't actually rename TLS 1.3, because at the end
we = will merely create a new name for it.=C2=A0 It has already been TLS 1.3 for= a few
years, it has been discussed in the tech community as TLS = 1.3, researchers have
published papers about TLS 1.3, there's= probably already the marketing material
with TLS 1.3 out there.= =C2=A0 The code that refers to it as TLS 1.3 will probably
end up= being referring to it as 1.3 for approximately forever, even if all the
implementers had been enthusiastic about renaming it, because refac= toring is
high-cost and low-priority, and may not be even possibl= e if you've already
exposed it via the ABI.=C2=A0 The old nam= e will never die, and it will be a burden
to anyone in this commu= nity, making confusing versioning scheme even more
confusing.=C2= =A0 It will probably leak outside of it too, and instead of (2), we
will end up getting

=C2=A0 =C2=A0 SSL 2 -> S= SL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 1.3 =3D TLS 4 =C2= =A0 =C2=A0 =C2=A0(4)

which seems strictly more con= fusing than (1) in any way.

tl;dr: the only way to= minimze confusion at this point is to not change
anything.
=
--001a114e718ec0f0bd0541a1a199-- From nobody Fri Nov 18 22:49:47 2016 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 A18BD129446 for ; Fri, 18 Nov 2016 22:49:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1 X-Spam-Level: X-Spam-Status: No, score=-1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 jgZvfhMDa8W1 for ; Fri, 18 Nov 2016 22:49:44 -0800 (PST) Received: from mail-wj0-x22b.google.com (mail-wj0-x22b.google.com [IPv6:2a00:1450:400c:c01::22b]) (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 08DBA1293FB for ; Fri, 18 Nov 2016 22:49:44 -0800 (PST) Received: by mail-wj0-x22b.google.com with SMTP id xy5so5188056wjc.0 for ; Fri, 18 Nov 2016 22:49:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=QM9YVM/eP8H5cghuUaJ0jYAeOWERAdhhWsQNnv38mW0=; b=cz89zURhb7JTNGsxYeIVmiiD474pnWvq34cdU7EuixCaa6+EfHzRTTAeWw6i4JNb// TIJYI67I/UvijfTZ60t2QAveES9TEj5ufk4co7lyfprlDL4CtJYGM5Dm2QjfCqkMeMN6 MBdZWbJokYDcAFHX38tV+ZWwsUh+JICwBFYPRXJ6c2jZcHvRLxEm1/lvHkINHpXwKaWG 9/9zxCcR6WWD0lWm7AwOXqKEWhGyJXudOZZpp1KoYF4lfrFuCDuhcXs/h1xIOUbqqfgw YwNrl4pEW6dRcIiMqKwc4AyuWLRglqT/3WuAbyQpYwQ+vwnnvDanm/21COlPGYZ106IG m95Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QM9YVM/eP8H5cghuUaJ0jYAeOWERAdhhWsQNnv38mW0=; b=ftLN5gnBX5HSYeTP6ujBWxY2BjYl2HMmvxt0yU1YCwz4+CFMY0KeZm/J6eMfLlxW3G iSZ+c1XcMw+5GjMeiSmqRztQcT/Jy3QzLuMuuTuatb1Tmv2JdQrmgCMMLgvxAiTXvZEf A3UAA8nmmUCGrr8VR8P2JjVLq57WJReY2zWizAG+xIK8pJxTPO6C9qy5OiytD24uuiRn dqOq70nVfgdK+qnEnwRZf5Mj/8ORw8IfMEwRlCCdz3YgaxZuBTZNXAlOxxzURDJyLr/q T++Sa1sJd0ulhA2LZm7BbJJ4IAuc6xspNH/1z3LzW6MH22ehpT5XPTGgBreP27JXDatQ zvJA== X-Gm-Message-State: AKaTC01D7TkrPuTkefAQIkzTPDlOBIQvaIZHeVQ6byOkEYVtYgxhRzm1b2C9RJPljpwCug== X-Received: by 10.194.60.195 with SMTP id j3mr2113209wjr.149.1479538182392; Fri, 18 Nov 2016 22:49:42 -0800 (PST) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id g197sm7158601wmd.15.2016.11.18.22.49.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Nov 2016 22:49:41 -0800 (PST) To: Victor Vasiliev , Kazuho Oku References: <20161118180737.16475.qmail@cr.yp.to> From: Anders Rundgren Message-ID: <4467b475-d17e-581a-a142-4a0a7c2708f9@gmail.com> Date: Sat, 19 Nov 2016 07:49:29 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 06:49:45 -0000 On 2016-11-19 07:35, Victor Vasiliev wrote: > On Fri, Nov 18, 2016 at 9:30 PM, Kazuho Oku > wrote: > > I oppose to going to TLS 4, due to the following reasons: > > * it might give people false notion that SSL 2.0, 3.0 is superior to TLS 1.0-1.2 > * if name the new protocol TLS 1.3, 2.0, or 2, then there would be no confusion once SSL goes away. However, if we name the new version TLS 4, then people would (for upcoming tens of years) continue to ask where TLS 2 and TLS 3. Windows 9 never made it to the public. Hardly nobody complained. If the TLS protocol you are working on is "Brand New" or is just an "Incremental Upgrade" is more a matter of personal opinion than an absolute truth. It is definitely a "Major Overhaul" since every little bit of the protocol has been reviewed thoroughly. TLS 4 seems OK to me. Anders > > > I very much agree with those points. > > TLS 4 is a confusing name that, as far as I can tell, cannot actually make > things better. Right now we have: > > SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 1.3 (1) > > Now, some people may get confused by this because of the "SSL is TLS" idea, but > once you learn that in reality "SSL is a thing that was before TLS", it does > make sense and seem fairly straightforward (a series of numbers under one name, > followed by another series of numbers under the new name). > > With TLS 4, we have: > > SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 4 (2) > > This does has a nice property of indicating that TLS 4 is clearly the latest > version (as long as you know that SSL came before TLS), but omission of TLS 2 > and TLS 3 will leave people confused, and most likely lead them to conclude > that what happened is TLS was renamed to SSL and then back again, so that > > TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> SSL 2 -> SSL 3 -> TLS 4. (3) > > But this is not even the worst of the problems. > > The real problem is that we can't actually rename TLS 1.3, because at the end > we will merely create a new name for it. It has already been TLS 1.3 for a few > years, it has been discussed in the tech community as TLS 1.3, researchers have > published papers about TLS 1.3, there's probably already the marketing material > with TLS 1.3 out there. The code that refers to it as TLS 1.3 will probably > end up being referring to it as 1.3 for approximately forever, even if all the > implementers had been enthusiastic about renaming it, because refactoring is > high-cost and low-priority, and may not be even possible if you've already > exposed it via the ABI. The old name will never die, and it will be a burden > to anyone in this community, making confusing versioning scheme even more > confusing. It will probably leak outside of it too, and instead of (2), we > will end up getting > > SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 1.3 = TLS 4 (4) > > which seems strictly more confusing than (1) in any way. > > tl;dr: the only way to minimze confusion at this point is to not change > anything. > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Nov 19 03:32:12 2016 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 12D1E12966D for ; Sat, 19 Nov 2016 03:32:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAEl5jd2InOX for ; Sat, 19 Nov 2016 03:32:07 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 BD2A0129669 for ; Sat, 19 Nov 2016 03:32:07 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id j65so5321712iof.0 for ; Sat, 19 Nov 2016 03:32:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=W4xzLI60veE/jDDCCAz7tcPm+dnKxv3kvp7b5U8g8eM=; b=jxKZnd/ac7pvieMkHiRHFEr+/FldyoYVe5GdxdJlbBbWtlnP/J9dyMqsq/qo4Bm72L l9vxIO1mjTiTwG3iaj1NcbuzqZGr4SBvQFuckKkJpvQDbNPcJs8EqH/WRTGCU/6F119v CIzsfbdPV+SItw0D5Gh1xm9kWbxP4W7AJN4ESKjOpLFktWhfTOKov3x3H/u7K9NdYhIF cIuQHsmH37nddX/F8+P95L1hS93ihy0Y1b0MxuGKReUvV29jkiQ4G2QWahQhFyO2kvT9 DoF0Icg9czZ1i+3dHGJq5xubAcSa7qXrBMYgToQIwrJ8a/ow2N0687bOR3Q+27hzxMEK E/jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=W4xzLI60veE/jDDCCAz7tcPm+dnKxv3kvp7b5U8g8eM=; b=lgqLz+hBuyCCVE1BetNVKzf8WyQBbmHOSo4R0MvH/VsQT6+VqkeyrX8vMbV3prFP0B bShjc5NynvduL5tM0vT5ku+aq7xQ9lrwhNCFbunGQcF/6RM2LxXQYuztoUv9X/AZ2p1r Mo/Dt2QxvduyvnDJeQCyDk+6po9W15NMVZf628GGTZ4T17VjOav5leyTPLvQzuj8xj0V FfFNoQp+ux94BS0fwBOw85i4sF7Zo8NLUnaH50+eJWwj3FMHDkuklxoBvZkg8hBBgOcz hS2QaX/tFeosF24hcK+57k3cNSmMgFAFEGHmbax7aJFqitFspaxIc8W67PPn5MK8ZmCo 1Rkg== X-Gm-Message-State: AKaTC01/4aUPZZUSZSc3rgOJfKe06m0NqiHbIjviCdKEAy2BtvpiyvPugb/sgg9c9ZtHkCLu1bi/W8ab3rdSlg== X-Received: by 10.107.156.75 with SMTP id f72mr3674491ioe.9.1479555127164; Sat, 19 Nov 2016 03:32:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.33.205 with HTTP; Sat, 19 Nov 2016 03:32:06 -0800 (PST) In-Reply-To: References: From: Jeffrey Walton Date: Sat, 19 Nov 2016 06:32:06 -0500 Message-ID: To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: noloader@gmail.com 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: Sat, 19 Nov 2016 11:32:09 -0000 On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should rebrand TLS1.3 to something else. Slides can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. Please forgive my ignorance... Who are you targeting for the versioning scheme? Regular users? Mom and pop shops with a web presence? Tech guys and gals? Security folks? For most tech people and security folks, I don't think it matters much. However, how many regular users would have clung to SSLv3 and TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and TLS 1999 (given TLS 2008 or TLS 2010 was available)? (Sorry to violate the Hum restriction). Jeff From nobody Sat Nov 19 03:40:29 2016 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 06BFB129674 for ; Sat, 19 Nov 2016 03:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 RY5yv4wEX3nm for ; Sat, 19 Nov 2016 03:40:26 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38148129673 for ; Sat, 19 Nov 2016 03:40:26 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 377A1284EA9; Sat, 19 Nov 2016 11:40:25 +0000 (UTC) Date: Sat, 19 Nov 2016 11:40:25 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20161119114025.GT26244@mournblade.imrryr.org> References: <20161118180737.16475.qmail@cr.yp.to> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org 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: Sat, 19 Nov 2016 11:40:28 -0000 On Sat, Nov 19, 2016 at 01:35:41AM -0500, Victor Vasiliev wrote: > TLS 4 is a confusing name that, as far as I can tell, cannot actually make > things better. Right now we have: > > SSL 2 -> SSL 3 -> TLS 1.0 -> TLS 1.1 -> TLS 1.2 -> TLS 1.3 (1) > > Now, some people may get confused by this because of the "SSL is TLS" > idea, but once you learn that in reality "SSL is a thing that was before > TLS", it does make sense and seem fairly straightforward (a series of > numbers under one name, followed by another series of numbers under the > new name). This feels like a contrived and speculative argument, backed by no evidence. There is on the other hand actual user confusion with the current numbers. We should not rationalize personal preferences with plausible, and yet non-factual arguments. It is fine to just state a preference. If a majority of the WG prefers the status quo because 3 is a Gaussian prime, and 4 is bad karma in China (*), then that's sufficient, the reasons don't actually have to be rational. -- Viktor. (*) Some decades back, shortly before the hand-over of Hong-Kong to China, there was a property boomlet in Melbourne, and IIRC some streets sprouted houses numbered 3+1/2... From nobody Sat Nov 19 03:51:26 2016 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 8DE27129694 for ; Sat, 19 Nov 2016 03:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 MvdEcJ2i3KDW for ; Sat, 19 Nov 2016 03:51:22 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07EE1129690 for ; Sat, 19 Nov 2016 03:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1479556282; x=1511092282; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=b7X+H3bvZC1kc6H6LUeOWJxdDh9yLwhKoaJl3c7ABjo=; b=SXUQfIZrNLk38u5KANomYD2Ih+VMX7yXPZgpXcH47pbOLXQNI5XTjtJm uNMr8+kpzySPvaYalx3QsR2V7PblHWA19h8+2R40JLnYmS/4kX+JV4iJS 1RID+hqKdwdSvPHMg4XbGh+lRX4tFnvThkuhbvHLSHUETxn7Ojb18zcuR 0g9kdn8L4++EcPQ9rWkDTUHlJ1brT9JzcranLK+n4CeV60EQKImkjY8xl LEc7pfzN10uGmf2lxOYqhnYezUBDT0ElGwK5mgInIANrrzHErFeQ7KHNL KYbf7/T29Oa5YY7F59FFQxgGweRi2JaVdf1v7lZ5mMC3BQtT0C+7SkB4Q A==; X-IronPort-AV: E=Sophos;i="5.31,515,1473076800"; d="scan'208";a="115936476" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Nov 2016 00:51:20 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 20 Nov 2016 00:51:19 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sun, 20 Nov 2016 00:51:19 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFcD667DaatoU6RNleDGo1T66DeMNiAgABKBQCAAEKcgIAARGGAgABVJICAANvyNQ== Date: Sat, 19 Nov 2016 11:51:18 +0000 Message-ID: <1479556268057.28362@cs.auckland.ac.nz> References: <20161118180737.16475.qmail@cr.yp.to> , <20161119114025.GT26244@mournblade.imrryr.org> In-Reply-To: <20161119114025.GT26244@mournblade.imrryr.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 11:51:25 -0000 Viktor Dukhovni writes:=0A= =0A= >If a majority of the WG prefers the status quo because 3 is a Gaussian pri= me,=0A= >and 4 is bad karma in China=0A= =0A= Just as long as we don't end up going for version 8888.=0A= =0A= Peter.= From nobody Sat Nov 19 03:56:15 2016 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 D39BF1296A4 for ; Sat, 19 Nov 2016 03:56:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 aBJFdyYVifhZ for ; Sat, 19 Nov 2016 03:56:14 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C8C3129847 for ; Sat, 19 Nov 2016 03:56:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1479556573; x=1511092573; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=YYxaDwb5H5kguaOCDLB1udxovduKABSWidFRZ+poK64=; b=fUmddCB//ObYXOU3U3mhHov1ST5BhyfdoY0qLWWay6eT/j3Ke/LBdwmH YwhoBvxoAGX7MQsaeb+1hYq+YbmBYaqoQxJOAVRkv2SNUFPu60u7C9TgX 8j66D0vhMZEIxLfwM4ydv+xGZ+FykXicEtHxwssiJUmx2TZ06ZmQyJc/e ezSxTyADTINoOOM1BlJBog//nwijrv9fAc98b84OCioKD6HtdojGn//nb JuwnuwB6Qu8ZBC6qOtquQu3O2ughVydEnu/mQxx2dkvA0Zt1d+J/1VWGZ qWSETb2iePJ3Nbqdxni5OCCQUPKzysoXUw2pJtBstIZdXpDfY1b8IfD7Q A==; X-IronPort-AV: E=Sophos;i="5.31,515,1473076800"; d="scan'208";a="115936862" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.5 - Outgoing - Outgoing Received: from exchangemx.uoa.auckland.ac.nz (HELO uxcn13-ogg-d.UoA.auckland.ac.nz) ([10.6.2.5]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 20 Nov 2016 00:56:12 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 20 Nov 2016 00:56:12 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Sun, 20 Nov 2016 00:56:11 +1300 From: Peter Gutmann To: Ilari Liusvaara Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFcD667DaatoU6RNleDGo1T66Ddz30AgADmRXP//1ILgIABkg4f//9lsICAATWn3A== Date: Sat, 19 Nov 2016 11:56:11 +0000 Message-ID: <1479556560914.73675@cs.auckland.ac.nz> References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz> <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> <1479523253827.80996@cs.auckland.ac.nz>, <20161119062725.GA30600@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20161119062725.GA30600@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 11:56:15 -0000 Ilari Liusvaara writes:=0A= =0A= >Nope, I was referring to the very technical property that if client sends = a=0A= >TLS 1.3 handshake, a TLS 1.2 server can still successfully interop, provod= ed=0A= >that the client does TLS 1.2 too=0A= =0A= That's like saying that PGP and S/MIME are compatible because if a client= =0A= sends a PGP message, a MIME-enabled server can still successfully interop= =0A= provided the S/MIME server does PGP too.=0A= =0A= Anyway, it's a silly debate (as my Wozniak joke tried to point out), so I'l= l bow =0A= out now.=0A= =0A= Peter.=0A= From nobody Sat Nov 19 05:31:33 2016 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 8C5FD129682 for ; Sat, 19 Nov 2016 05:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9WIBe0T-rF3 for ; Sat, 19 Nov 2016 05:31:29 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::22e]) (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 4E8E012968C for ; Sat, 19 Nov 2016 05:31:29 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id j65so6641112iof.0 for ; Sat, 19 Nov 2016 05:31:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cFfLCJygo24dXk3PGWyNnVhAubJSsq3pyzlGaGJSAFI=; b=AG9sVMngb9s/GSy7fDqBPzv4RAUvrOt74R1lZ2XMtALQnRkeYH/XkS0ShyG7/yc5tn rsUzAF9jJsTeW7cS5LlI3p/BgFAkDTmuuo41Kbo2IILTfAYu9fGgczC4iOcmHQUg0QqU YX87dOD0wUp5areTwNQEgEFLXNIjmDXTmEZBpF3nNIGrHu0GQtNezVpoZH1i/q1GtzJB 6hQi3MYqpP244cVskN5s78Jg/J2vlzLftScwA24XGFOwSVtcT8MIOd8Pc87Rz3lnBFPI 3RF+QZyn/PSbXM6uMqAPeAF9VkqWOdESfTv/sdOOsvjyfh3X9h3HsndPI2/TlZ3xgODV tL6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cFfLCJygo24dXk3PGWyNnVhAubJSsq3pyzlGaGJSAFI=; b=KxI+/1Ne7tnZkNW9/He/b2I3fFEYG0yU/ngGNGSR1ixN2ujpdCOLBsoY/690z4kdBm 3ujYnUBDnJ2llMHFe3kpyW02u7/2utNVyVBj7YbL5xhxc4WLaqe+42vKgDOebE3wKzVn evNWHwEoY4rzNmHX+55qfQbKHpmVzCBME+0VgNfoKgl4Euhj3UnQBbAUDF/SATbPqAR6 /eFr35nfhGPHbmZsBm2jhul+XIswqf/93UWIg/H1aXrFQRAKlt6+Ywj4fuHDvPGraVeg Oivz4Aksl38+EZHBAXV0MbTa6haLD4mtNgy9sizCyzUJOoFode/ff/nXD1Z0mjaxBbHX ydew== X-Gm-Message-State: AKaTC017tc6JThm7CHNm8PevNZmzdCSGwUTGED+l97ezqVrOEIwC5+Zhdb9TozGPVT80iHhsMzUcSRh/SM9BUg== X-Received: by 10.107.33.194 with SMTP id h185mr3926219ioh.18.1479562288506; Sat, 19 Nov 2016 05:31:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.8.101 with HTTP; Sat, 19 Nov 2016 05:31:07 -0800 (PST) In-Reply-To: References: From: Ira McDonald Date: Sat, 19 Nov 2016 08:31:07 -0500 Message-ID: To: noloader@gmail.com, Ira McDonald Content-Type: multipart/alternative; boundary=001a1140ecb0a12da10541a77063 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 13:31:31 -0000 --001a1140ecb0a12da10541a77063 Content-Type: text/plain; charset=UTF-8 Hi, I think that the presumption that most tech people (or even security people) won't have any trouble with the future version numbering of TLS is wrong. Yesterday morning, on an SAE Vehicle Electrical Systems Security call with some 40 auto security professionals present, I mentioned that TLS 1.3 was wrapping up and was asked "What's TLS?" Usual explanation about SSL being succeeded by IETF TLS 17 years ago. Several responses that were the equivalent of blank stares. And finally, "Then why is the library still called OpenSSL?" Rich has highlighted that the tech community goes right on conflating SSL with TLS on web sites. I change my two cents to "TLS 4" but am unsure about "4" or "4.0" because the tech community has been trained to care about major.minor. Cheers, - Ira Ira McDonald (Musician / Software Architect) Co-Chair - TCG Trusted Mobility Solutions WG Chair - Linux Foundation Open Printing WG Secretary - IEEE-ISTO Printer Working Group Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG IETF Designated Expert - IPP & Printer MIB Blue Roof Music / High North Inc http://sites.google.com/site/blueroofmusic http://sites.google.com/site/highnorthinc mailto: blueroofmusic@gmail.com Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 On Sat, Nov 19, 2016 at 6:32 AM, Jeffrey Walton wrote: > On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG > should rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-rebranding-aka-pr612-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to > not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this > decision on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. > > Please forgive my ignorance... > > Who are you targeting for the versioning scheme? Regular users? Mom > and pop shops with a web presence? Tech guys and gals? Security folks? > > For most tech people and security folks, I don't think it matters > much. However, how many regular users would have clung to SSLv3 and > TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and > TLS 1999 (given TLS 2008 or TLS 2010 was available)? > > (Sorry to violate the Hum restriction). > > Jeff > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1140ecb0a12da10541a77063 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=

I think that the presumption that most tech people (or even s= ecurity people)
won't have any trouble with the future version= numbering of TLS is wrong.

Yesterday morning, on an SAE Vehic= le Electrical Systems Security call with
some 40 auto security pro= fessionals present, I mentioned that TLS 1.3 was
wrapping up and w= as asked "What's TLS?"=C2=A0 Usual explanation about SSL
<= /div>being succeeded by IETF TLS 17 years ago.=C2=A0 Several responses that= were
the equivalent of blank stares.=C2=A0 And finally, "The= n why is the library still
called OpenSSL?"

Rich= has highlighted that the tech community goes right on conflating SSL
with TLS on web sites.

I change my two cents to "TLS 4"= ; but am unsure about "4" or "4.0" because
the tech community has been trained to care about major.minor.

Cheers,
- Ira


Ira McDonald (M= usician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions = WG
Chair - Linux Foundation Open Printing WG
Secretary - IEEE-ISTO Pr= inter Working Group
Co-Chair - IEEE-ISTO PWG Internet Printing Protocol = WG
IETF Designated Expert - IPP & Printer MIB
Blue Roof Music / H= igh North Inc
http://sites.google.com/site/= blueroofmusic
http://sites.google.com/si= te/highnorthinc
mailto: blueroofmusic@gmail.com
Jan-April: 579 Park Place= =C2=A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
May-Dec: PO Box 221=C2= =A0 Grand Marais, MI 49839=C2=A0 906-494-2434


On Sat, Nov 19, 2016 at 6:32 AM, Jeffrey Wal= ton <noloader@gmail.com> wrote:
On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner <sean@sn3rd.com> wrote:
> At IETF 97, the chairs lead a discussion to re= solve whether the WG should rebrand TLS1.3 to something else.=C2=A0 Slides = can be found @ h= ttps://www.ietf.org/proceedings/97/slides/slides-97-tls-rebrandin= g-aka-pr612-01.pdf.
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not rebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this d= ecision on the list so please let the list know your top choice between: >
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4
>
> by 2 December 2016.

Please forgive my ignorance...

Who are you targeting for the versioning scheme? Regular users? Mom
and pop shops with a web presence? Tech guys and gals? Security folks?

For most tech people and security folks, I don't think it matters
much. However, how many regular users would have clung to SSLv3 and
TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and
TLS 1999 (given TLS 2008 or TLS 2010 was available)?

(Sorry to violate the Hum restriction).

Jeff

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1140ecb0a12da10541a77063-- From nobody Sat Nov 19 06:31:27 2016 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 5F204129975 for ; Sat, 19 Nov 2016 06:31:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wmTp8Z4JodoO for ; Sat, 19 Nov 2016 06:31:24 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 F059D129973 for ; Sat, 19 Nov 2016 06:31:23 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id 3so113579078pgd.0 for ; Sat, 19 Nov 2016 06:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=sm1L9nimrrWczhRMQa1d7OBqIJcgHczU/Z4eSEgmC/0=; b=YCMaAaBTHLP/KXmC5bdv2X1QOOmDOkOY9rt4snDWauNbtYNFmjyxzgA/Lj6402/pvp le8Ks//02J1I6NhMTywuHFmjAC5V+jTP3NtbAcQvTjHCCzC7xcqS5X6q+amGN29emWxI 0L3pL6KOXF2Eu07VJgPGb2uchbNpZskFdeyK2z7QLK3Bne/y9ebqrBrEwUG/Q6jzWtJA 5GNhdCpeWbP+s+8m4qvze/OJlZd7huftzUbiqYIg9bJPgZIupRCUtD3cLJp7yv9PT8hN +hKchO1w42m39AndHWXiSl8swpZouSMPKe5O8kKSlHrMgCBjVGtCzrEkEyzChx4pR8Ck eA/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=sm1L9nimrrWczhRMQa1d7OBqIJcgHczU/Z4eSEgmC/0=; b=asoU7KBYTlQq7MI70ueIzuSjI5Ufc/LXvQ+Id3G9Wu+8LS0xzAFjrLOhjcB+CaUPuQ kKvZ2/iYtCmt4bsiEkZKyF83S1AyUrkhIuvIKpOw0GHqhjYFGbWO2pSn4uhjr6m3Xec3 mMv2VQIaNwUEN+G3pOv/UL5ochFbC8iwx0o7WCX9Vw8LkbSe30jJBk38dRS+Qg6HNMsK X4V50ZhGGN5yaLmbxS/GCCqtL/vyoixQJzNEpGsoagPqaVw00bWNMYbAEWN47T27SEfo aWtKiDW5GuAfWDUOtmux2GGHZW69p8t+b92EExjA+fKIqJSmwbCDUxxNt3A46zsMFdn3 JWnw== X-Gm-Message-State: AKaTC03NiObG2Gp8lhOx2cb606/1UfDl9fPpF9sNUCIlZSEEcmJUnSCsWlW8foL1DmCCSg== X-Received: by 10.99.114.89 with SMTP id c25mr11132951pgn.4.1479565882920; Sat, 19 Nov 2016 06:31:22 -0800 (PST) Received: from [10.20.100.92] ([58.120.104.2]) by smtp.gmail.com with ESMTPSA id z9sm25611689pfd.29.2016.11.19.06.31.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Nov 2016 06:31:21 -0800 (PST) To: Sean Turner , "" References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> From: Yaron Sheffer Message-ID: <04450ca1-e849-40ff-fc09-52278772cbb2@gmail.com> Date: Sat, 19 Nov 2016 23:31:18 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 14:31:25 -0000 I have not read the document in full (but still noticed a typo in the paragraph we're discussing), so I will not comment on its readiness. Regarding signature context: I don't understand the CFRG recommendation that Yoav is citing. IMO we should include a context string wherever we can, to reduce the number of possible cross-protocol (or cross-signature scheme) attacks. As far as I know context strings do not cost anything and can only improve the protocol's security. Maybe one day we will only have signatures deployed that support context, but if we don't add the context string now we will never get there. We are not going to revise TLS just to add a context string to EdDSA. Thanks, Yaron On 19/11/16 08:55, Sean Turner wrote: > All, > > This is a working group last call for the “4492bis to Standards Track" draft available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/. Please review the document and send your comments to the list by 9 December 2016. > > Note that we are particularly interesting in the issue Yoav raises in the following message: > https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk > > Thanks, > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Sat Nov 19 08:28:51 2016 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 44CD712960B for ; Sat, 19 Nov 2016 08:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 POuFVQrpcW5Z for ; Sat, 19 Nov 2016 08:28:46 -0800 (PST) Received: from mail-pf0-x236.google.com (mail-pf0-x236.google.com [IPv6:2607:f8b0:400e:c00::236]) (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 2E884129518 for ; Sat, 19 Nov 2016 08:28:46 -0800 (PST) Received: by mail-pf0-x236.google.com with SMTP id c4so46633947pfb.1 for ; Sat, 19 Nov 2016 08:28:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g5lLpZmZGKApEY2hcaDcfdkf301ofkqVfzyTwVtGWTw=; b=mi/8/3zKFf2mOttfjv2j3DxB8bEldP/lYqMH0V8Fall5Wj67nuzEwwWxQnPWHzt4vD 1XCmfx1gUUV+vhzGySdmD0900+l5KThmXOu+M8uGUblLLqL5/o0GPU5I+m5Pf/rUmZaG AIdH6wtfmi5rHaUjuUc7idhQm3ie76sdpeyPU= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=g5lLpZmZGKApEY2hcaDcfdkf301ofkqVfzyTwVtGWTw=; b=W+b+tghR6b815Wfd6+AsXn7xNECdRvmN0e0Dkq6dKueQ67avHwgzzzuQNaPpwYo/Nb v1rM/GTI0hVNNtF98XBFqcmsDLf93KQGNYJcIPgBISKHQ7FpChPVJ8rrTLzWnjmp1L40 DrqEbt/Tm6r1fovpzgb3ohc8Hu4bXWTYX5V+bMz0Yq5/xfhK9R3/AzyJLV8A5WlUpO3W YVafFVSNrBPmprH0ng/gPgvWYzw8Vmrf4XpqpWTvythqE+TQRlg3C6HWR40Dy4h5FxuV Ekz+sJK0J1e5gv1FB5BmV5RMeBo6uZFn0puTa3LhRP/eOQouC1u9WEwLf8qFx9ycrhKd gjdA== X-Gm-Message-State: AKaTC01iNsb7gKXvW7zXLbE70W/gu+4uNUxqMLglO+l5vC9+KKO7Onz6EtbkS0MoNaTYVPGM X-Received: by 10.98.34.68 with SMTP id i65mr7101602pfi.135.1479572925204; Sat, 19 Nov 2016 08:28:45 -0800 (PST) Received: from ?IPv6:2601:645:8302:ef30:f980:43c0:1777:efa3? ([2601:645:8302:ef30:f980:43c0:1777:efa3]) by smtp.gmail.com with ESMTPSA id b12sm23800797pfb.78.2016.11.19.08.28.42 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 19 Nov 2016 08:28:42 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Vlad Krasnov X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Sat, 19 Nov 2016 08:28:41 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <75CEEAC9-2722-4E36-B84D-F07CDF10BC20@cloudflare.com> References: To: Ira McDonald Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 16:28:49 -0000 "Then why is the library still > called OpenSSL?" All those arguments show basic confusion of what TLS is. Version numbers won= 't help solve that.=20 Only going back to using the SSL name might.= From nobody Sat Nov 19 08:40:02 2016 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 2133912961B for ; Sat, 19 Nov 2016 08:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.2 X-Spam-Level: X-Spam-Status: No, score=-2.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 8fD7ktwsjO4t for ; Sat, 19 Nov 2016 08:39:58 -0800 (PST) Received: from mail-oi0-x22a.google.com (mail-oi0-x22a.google.com [IPv6:2607:f8b0:4003:c06::22a]) (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 E7A791295AB for ; Sat, 19 Nov 2016 08:39:57 -0800 (PST) Received: by mail-oi0-x22a.google.com with SMTP id v84so120176667oie.3 for ; Sat, 19 Nov 2016 08:39:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SM68pD/tKXEOOFMKxW6440GOgdyXNlEKSnBjK6S1Gsw=; b=MsOfenBa5OlF1FjSLtQL1+8Jmwf3xTaqRiOeyS1hQabn6aSU9HiCK2MgrBZTZK51ZT vOfSQlfmandRKyYyH93143a9gp4jpSp7w0b6xVkuqcz1VG5bCKYw2pm5l6rNlHJqiaVF gsIrW2wrSetUK7PEN6hMlB8n6pwvDct9k2jd4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SM68pD/tKXEOOFMKxW6440GOgdyXNlEKSnBjK6S1Gsw=; b=euZSiXJJKmGpxTlaaroHyh5pMqe2JOSN8zX3cF29z5NzEl+d3Bw4pTiHqFk2iKajwe XTcI7Ibld7jbyQVruBiGZ2cx4PVsVA/dxjFZQRsQCnsfr9B7RvE0JW+1DJ+PHmTjPJs3 lf/qd9C32IDUf6IUVFoihoPA/DKKtvFgWxbRHZO7BM7k6xsepT864nPoz0F1N2GaadoB fHp+ABpynkExkGf11NbFTv16jZImb7yYRTZvA6HU8fbo2MR6eh5IYmdneOWa3G2zvxNo 7hAAXPSepMlFvSlNyicWaHiA4yg04gwg5CnDXjrpBxusKHu4b9loEC6eT+C/pPdSqxoT dvBQ== X-Gm-Message-State: AKaTC02Mqf7k7dpJHR99Pv/rJEftjat3bSaj8Jg0n8600IT0gFlYuPXDD7b98bHZyoHap7MW X-Received: by 10.157.47.250 with SMTP id b55mr3652556otd.236.1479573597101; Sat, 19 Nov 2016 08:39:57 -0800 (PST) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com. [209.85.218.45]) by smtp.gmail.com with ESMTPSA id s130sm4243911oif.3.2016.11.19.08.39.56 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 19 Nov 2016 08:39:56 -0800 (PST) Received: by mail-oi0-f45.google.com with SMTP id z62so120214785oiz.1 for ; Sat, 19 Nov 2016 08:39:56 -0800 (PST) X-Received: by 10.202.114.129 with SMTP id p123mr3433176oic.132.1479573596163; Sat, 19 Nov 2016 08:39:56 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Steven Valdez Date: Sat, 19 Nov 2016 16:39:45 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Ira McDonald , noloader@gmail.com Content-Type: multipart/alternative; boundary=001a1134e0e89e8d110541aa1285 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 16:40:00 -0000 --001a1134e0e89e8d110541aa1285 Content-Type: text/plain; charset=UTF-8 Maintaining my hum from the meeting, I prefer keeping TLS 1.3 over renaming, primarily because there's now a good amount of documentation/implementation in the wild that refers to TLS 1.3, and we'll need to keep around the new equivalence of TLS 2 (or 4)=TLS 1.3. On Sat, Nov 19, 2016, 8:31 AM Ira McDonald wrote: > Hi, > > I think that the presumption that most tech people (or even security > people) > won't have any trouble with the future version numbering of TLS is wrong. > > Yesterday morning, on an SAE Vehicle Electrical Systems Security call with > some 40 auto security professionals present, I mentioned that TLS 1.3 was > wrapping up and was asked "What's TLS?" Usual explanation about SSL > being succeeded by IETF TLS 17 years ago. Several responses that were > the equivalent of blank stares. And finally, "Then why is the library > still > called OpenSSL?" > > Rich has highlighted that the tech community goes right on conflating SSL > with TLS on web sites. > > I change my two cents to "TLS 4" but am unsure about "4" or "4.0" because > the tech community has been trained to care about major.minor. > > Cheers, > - Ira > > > Ira McDonald (Musician / Software Architect) > Co-Chair - TCG Trusted Mobility Solutions WG > Chair - Linux Foundation Open Printing WG > Secretary - IEEE-ISTO Printer Working Group > Co-Chair - IEEE-ISTO PWG Internet Printing Protocol WG > IETF Designated Expert - IPP & Printer MIB > Blue Roof Music / High North Inc > http://sites.google.com/site/blueroofmusic > http://sites.google.com/site/highnorthinc > mailto: blueroofmusic@gmail.com > Jan-April: 579 Park Place Saline, MI 48176 734-944-0094 > May-Dec: PO Box 221 Grand Marais, MI 49839 906-494-2434 > > > On Sat, Nov 19, 2016 at 6:32 AM, Jeffrey Walton > wrote: > > On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG > should rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf > . > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to > not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this > decision on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. > > Please forgive my ignorance... > > Who are you targeting for the versioning scheme? Regular users? Mom > and pop shops with a web presence? Tech guys and gals? Security folks? > > For most tech people and security folks, I don't think it matters > much. However, how many regular users would have clung to SSLv3 and > TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and > TLS 1999 (given TLS 2008 or TLS 2010 was available)? > > (Sorry to violate the Hum restriction). > > Jeff > > _______________________________________________ > 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 > --001a1134e0e89e8d110541aa1285 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Maintaining my hum from the meeting, I prefer keeping TLS 1.3 over re= naming, primarily because there's now a good amount of documentation/im= plementation in the wild that refers to TLS 1.3, and we'll need to keep= around the new equivalence of TLS 2 (or 4)=3DTLS 1.3.


On Sat, Nov 19, 2016,= 8:31 AM Ira McDonald <bluero= ofmusic@gmail.com> wrote:
Hi,

I think = that the presumption that most tech people (or even security people)
won't have any trouble with the future version n= umbering of TLS is wrong.

Yesterday morning, on an SAE Vehicle Electrical Systems Security call w= ith
some 40 auto security professionals presen= t, I mentioned that TLS 1.3 was
wrapping up an= d was asked "What's TLS?"=C2=A0 Usual explanation about SSL
being succeeded by IETF TLS 17 years ago.=C2=A0= Several responses that were
the equivalent of= blank stares.=C2=A0 And finally, "Then why is the library still
called OpenSSL?"

Rich has highlighted that the tech community goes r= ight on conflating SSL
with TLS on web sites.<= br class=3D"gmail_msg">
I change my two cents to &qu= ot;TLS 4" but am unsure about "4" or "4.0" because=
the tech community h= as been trained to care about major.minor.

Cheers,
- Ira


Ira McDonald (Musician / Software Architect)
Co-Chair - TCG Trusted Mobility Solutions WG
Chair - Linux Foundation Open Printing WG
Se= cretary - IEEE-ISTO Printer Working Group
Co-Chair -= IEEE-ISTO PWG Internet Printing Protocol WG
IETF De= signated Expert - IPP & Printer MIB
Blue Roof Mu= sic / High North Inc
http://sites.google.com/site/blueroofmusic
http://sites= .google.com/site/highnorthinc
mailto: blue= roofmusic@gmail.com
Jan-April: 579 Park Place=C2= =A0 Saline, MI=C2=A0 48176=C2=A0 734-944-0094
May-De= c: PO Box 221=C2=A0 Grand Marais, MI 49839=C2=A0 906-494-2434


On Sat, Nov 19= , 2016 at 6:32 AM, Jeffrey Walton <= ;noloader@gmail.com> wrote:
On Thu, Nov 17, 2= 016 at 9:12 PM, Sean Turner <sean@sn3rd.com> wrote:
> At IETF 97, the chairs lead a discuss= ion to resolve whether the WG should rebrand TLS1.3 to something else.=C2= =A0 Slides can be found @ https://www.ietf.org/proceedings/97/slides/sl= ides-97-tls-rebranding-aka-pr612-01.pdf.
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not rebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this d= ecision on the list so please let the list know your top choice between: >
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4
>
> by 2 December 2016.

Please forgive my ignorance...

Who are you targeting for the versioning scheme? Regular users? Mom
and pop shops with a web presence? Tech guys and gals? Security folks?

For most tech people and security folks, I don't think it matters
much. However, how many regular users would have clung to SSLv3 and
TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and
TLS 1999 (given TLS 2008 or TLS 2010 was available)?

(Sorry to violate the Hum restriction).

Jeff

_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls

_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a1134e0e89e8d110541aa1285-- From nobody Sat Nov 19 09:46:11 2016 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 16DC91294F6 for ; Sat, 19 Nov 2016 09:46:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 39NKFvwwdM3W for ; Sat, 19 Nov 2016 09:46:07 -0800 (PST) Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::231]) (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 3A42E12940C for ; Sat, 19 Nov 2016 09:46:07 -0800 (PST) Received: by mail-ua0-x231.google.com with SMTP id 51so195762457uai.1 for ; Sat, 19 Nov 2016 09:46:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yr87HXSvKTaAsrKBVe3xPQl4JtVXZMORmqFNkTgIINo=; b=w7BHUBRy02hcVGxpt0qg9LiZukE+C2Q2ecJB9cXrz4ViUWbL1wqnshhc9pXgPBNaGs 4b+yKTaGM4z6KZ/M+kQUHZO8cix4PexWU0bno2tEI2fhPv40K7pUCQYTJc7eqSve8hnN hImwjuKvAkg68SQFMqzo//ng8wR09AQezA1bNBwWZCepdFBnnAl0g+i9ae07qaNCkHAJ QgY7jmV55XBgmX423FZtsJSA0OjKFH7/MEwF404Rn+oG57sbYRcn/nfxtoDDa1yXJbO4 tRSr4AC6Qz9oEJuRCgzJRIf9JSHXmRXXDe5rXAlKiu+k9emfNAUdx+R9vI019v/fR7+3 swZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yr87HXSvKTaAsrKBVe3xPQl4JtVXZMORmqFNkTgIINo=; b=AraqTzOEaUJ+9SsbdHeP2jLU1WCkoWqog/f6KyGIHA6BNtmiYisdvCAhtaDmDntGFh IMj42AK2CgPuCwXRNAK5Sz7hRT6mT16/rwC79ahpJ648AeRb+vfIfq4No5dBq88NlsCv lyzHbW49QG9WguYoIsuWVOAsRjz1757fNNexLnuiPrpZJGHu+PEP39s5RlcBJyZR3Mex sfhxUUPDu/wr/OfjgqNsPSZTIgSBm1yPNpa8CLES2KTXpcpj70hgfYxNIzjduATCu0Qo Qd+sgRJ3Iz8m81FsxBQOdLIQGfV75dWkeSRYi32zeeFMq9ZwyqwmGeZCiJAT3UMOPqrt VHAg== X-Gm-Message-State: AKaTC00UCv+ezB97DbMcO9GQ5usPvLuK4PW5FtIV3bzSDBlbZKJCavxqUwyPYAuJHkqWnHMhKwIwZmvVnVywBQ== X-Received: by 10.176.1.230 with SMTP id 93mr2498820ual.168.1479577566332; Sat, 19 Nov 2016 09:46:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.84.212 with HTTP; Sat, 19 Nov 2016 09:46:05 -0800 (PST) In-Reply-To: References: From: Judson Wilson Date: Sat, 19 Nov 2016 09:46:05 -0800 Message-ID: To: noloader@gmail.com Content-Type: multipart/alternative; boundary=001a1135de44424f700541aaff81 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 17:46:09 -0000 --001a1135de44424f700541aaff81 Content-Type: text/plain; charset=UTF-8 What Jeff said makes a ton of sense to me. "TLS 2017" would solve the problems that "TLS 4 solves," without being confusing, and with the added benefit that the age is painfully obvious. I see big wins all around. The downsides I see are that there is no major/minor distinction, and it would be hard to have 2 versions in a year - but I think both are small issues. On Sat, Nov 19, 2016 at 3:32 AM, Jeffrey Walton wrote: > On Thu, Nov 17, 2016 at 9:12 PM, Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG > should rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-rebranding-aka-pr612-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to > not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this > decision on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. > > Please forgive my ignorance... > > Who are you targeting for the versioning scheme? Regular users? Mom > and pop shops with a web presence? Tech guys and gals? Security folks? > > For most tech people and security folks, I don't think it matters > much. However, how many regular users would have clung to SSLv3 and > TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and > TLS 1999 (given TLS 2008 or TLS 2010 was available)? > > (Sorry to violate the Hum restriction). > > Jeff > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1135de44424f700541aaff81 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What Jeff said makes a ton of sense to me.

<= div>"TLS 2017" would solve the problems that "TLS 4 solves,&= quot; without being confusing, and with the added benefit that the age is p= ainfully obvious.=C2=A0 I see big wins all around.

The downsides I see are that there is no major/minor distinction, and it w= ould be hard to have 2 versions in a year - but I think both are small issu= es.

On Sat, No= v 19, 2016 at 3:32 AM, Jeffrey Walton <noloader@gmail.com> = wrote:
On Thu, Nov 17, 2= 016 at 9:12 PM, Sean Turner <sean@sn3r= d.com> wrote:
> At IETF 97, the chairs lead a discussion to re= solve whether the WG should rebrand TLS1.3 to something else.=C2=A0 Slides = can be found @ h= ttps://www.ietf.org/proceedings/97/slides/slides-97-tls-rebrandin= g-aka-pr612-01.pdf.
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not rebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this d= ecision on the list so please let the list know your top choice between: >
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4
>
> by 2 December 2016.

Please forgive my ignorance...

Who are you targeting for the versioning scheme? Regular users? Mom
and pop shops with a web presence? Tech guys and gals? Security folks?

For most tech people and security folks, I don't think it matters
much. However, how many regular users would have clung to SSLv3 and
TLS 1.0 (given TLS 1.2 was available) if they were named SSL 1995 and
TLS 1999 (given TLS 2008 or TLS 2010 was available)?

(Sorry to violate the Hum restriction).

Jeff

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1135de44424f700541aaff81-- From nobody Sat Nov 19 10:55:26 2016 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 A1CFE12950D for ; Sat, 19 Nov 2016 10:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2x3NXILBqow for ; Sat, 19 Nov 2016 10:55:24 -0800 (PST) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (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 A0BF712943C for ; Sat, 19 Nov 2016 10:55:24 -0800 (PST) Received: by mail-vk0-x22f.google.com with SMTP id x186so192093869vkd.1 for ; Sat, 19 Nov 2016 10:55:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SYiyPkflF7WzpZoXTZ7d4/xAMEIShCKnWtHn0IzIrL4=; b=ncu9MBYIOHDXBqTkO5Dy7yqb8sgCWCUEdCt2H+5toFtOZUdppDVnFVIriUWamNQHxz p8Z3+d/S0NHahOeXWS+JtKg/Ulry21GBRcA7krBpbxXCpEvhMdw1pAi0F6DEZmwq/j0s b6pLIMDR7zhl+ODvV8JizzbHcrdYdsmW8vbyy8JCMnnYCQm1FPh/v3yLmydrS9e6aO7J 9S7pYcRxBGIrA+HzCZ3xDczCl9y4XhRp/76B7WlUNk8xxU8+mKt7xn+FejVyls68BLgt +SRrPmLhFQmv5TsPN4cKDF4FgTjbkGeoe2odnjtTveFzEL3V/PoUutFkcxqxf+mQWo2k HO5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SYiyPkflF7WzpZoXTZ7d4/xAMEIShCKnWtHn0IzIrL4=; b=fwUiQYozOq1NH2wXztwgwE2S0Fj48bSQrcGoAKXdM7EavrP5VLaZuAZqw9LyMny5dd +aw1DlNzCiMeDBGhppP5nVYikTA/WjNsomJ2nZyqUDZNahnbfJf3cEiOgrpK7YbO+G5A GVAq0ND2JrT+lDkD5OdDF0Rr8Sb2rCCDrgKAQ8GaU1fLeTuPKVY5knITrnRMdeD54YGn LZSFnnk3GyfXcoYQncJxA9Hc0YpdnmEqEAOGBrlrip87EDKFZDvXPI9xealqBki2uEAx V3vdnsKO4rPoh5x15HHaqbU28XkaqzaJNW6uwzPl9oyWVdhPuTbuVSfUFs7zJvRl4lsS ldKQ== X-Gm-Message-State: AKaTC00sks5i6PZU3wW/MhQyx5dMDmYkdqyyhs3af4VEqOdAWuCY9NHETfmbwCUSZmDE/7MCcymbtWCZvENF5Q== X-Received: by 10.31.147.9 with SMTP id v9mr3019763vkd.90.1479581723775; Sat, 19 Nov 2016 10:55:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Sat, 19 Nov 2016 10:55:22 -0800 (PST) In-Reply-To: References: From: Watson Ladd Date: Sat, 19 Nov 2016 10:55:22 -0800 Message-ID: To: Sean Turner Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 18:55:25 -0000 Rebrand 4. There is no reason not to. From nobody Sat Nov 19 11:40:25 2016 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 5F51B1295CF for ; Sat, 19 Nov 2016 11:40:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 L0BbCM8zvl5t for ; Sat, 19 Nov 2016 11:40:20 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AB3E129577 for ; Sat, 19 Nov 2016 11:40:20 -0800 (PST) X-AuditID: c1b4fb30-96c1b98000001942-33-5830aaa2347d Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 9C.E7.06466.2AAA0385; Sat, 19 Nov 2016 20:40:18 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.62]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0319.002; Sat, 19 Nov 2016 20:40:06 +0100 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 Thread-Index: AQHSL/2+2v4l5+5kKUiyJ4qNLpCCr6DXocKAgAAe1ICAALIggIAI7NsA Date: Sat, 19 Nov 2016 19:40:05 +0000 Message-ID: References: <13C3DBCF-2609-4560-A194-1FA422BE7EEE@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.154] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplkeLIzCtJLcpLzFFi42KZGbFdVHfRKoMIg58btS0+ne9idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxr13nAVvsip+Lt3C1sDYk9HFyMkhIWAicXH5b+YuRi4OIYF1 jBLNu+4wQjiLGSWufF7GCFLFJmAgMXdPA1sXIweHiICixKfP2SBhYQE3ia0rFrCB2CIC7hL7 z25khbDdJGZN+QLWyiKgKnH06hewGl4Bc4n2fc+g5v9nlDjQv5kZJMEpYCfR8OMmWBGjgJjE 91NrmEBsZgFxiVtP5jNBXCogsWTPeWYIW1Ti5eN/rCD3iAroSay5HwYRVpJYdPszE0iYWUBT Yv0ufQjTWuLxGWGIgYoSU7ofskNcIyhxcuYTlgmMYrOQ7JqF0DwLoXkWkuZZSJoXMLKuYhQt Ti1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAiMnINbfhvsYHz53PEQowAHoxIPb4G4foQQa2JZcWXu IUYJDmYlEd4zCw0ihHhTEiurUovy44tKc1KLDzFKc7AoifOarbwfLiSQnliSmp2aWpBaBJNl 4uCUamCUyfg/45qhSJz3Pwan5k170iorpU9uenuRpUrr593MIpUT8judZ0cETzKN6V0nt+A8 h2FY95UI39cVWQdnuG4zmGsTV6Dm96sjifvjtG/Znx7/vzF5Qcrj8zzFMuZnf+R36CW9FK+Q mVhUV5GYZu/LdmZawhVGUW37AxuEp76uMg5OWv765C0lluKMREMt5qLiRAAFtO4OmAIAAA== Archived-At: Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sat, 19 Nov 2016 19:40:23 -0000 V0dMQyBjb21tZW50cyBvbiBkcmFmdC1pZXRmLXRscy10bHMxMy0xOA0KDQpIaSwNCg0KVmVyeSB3 ZWxsIHdyaXR0ZW4gZHJhZnQgYW5kIGFuIGV4Y2VsbGVudCBwcm90b2NvbC4gVGhlIHRoaW5ncyBJ IGhhdmUgZm91bmQNCmlzIG1vc3RseQ0KZWRpdG9yaWFsLiBJIHRoaW5rIGl04oCZcyByZWFkeS4g SSB3aWxsIHRyeSB0byBtYWtlIHN1cmUgdGhhdCAzR1BQIGFscmVhZHkNCm5leHQgeWVhcg0KbWFu ZGF0ZXMgc3VwcG9ydCBvZiBib3RoIFRMUyAxLjMgYW5kIERUTFMgMS4zIGluIGFsbCB0aGUgcGxh Y2VzIHRoZXkgdXNlDQooRClUTFMuDQoNCkNoZWVycywNCkpvaG4NCg0KDQotIEkgY2Fubm90IGZp bmQgYW55IHRleHQgZGVzY3JpYmluZyB0aGUgcmVxdWlyZW1lbnRzIFRMUyAxLjMgcHV0IG9uIHRo ZQ0KbG93ZXIgbGF5ZXJzLiBJbg0KICBmYWN0IHRoZSBvbmx5IHRleHQgSSBjYW4gZmluZCBpcyAi d2hpY2ggbWlnaHQgYmUgaGlkZGVuIGJ5IFRDUCIuIEkgZG9uJ3QNCiAga25vdyBpZiB0aGUgZHJh ZnQgc2hvdWxkIG1hbmRhdGUgVENQIG9yIG5vdCwgYnV0IG90aGVyd2lzZSBpdCBzaG91bGQgYmUN CnN0YXRlZCB0aGF0DQogIHJlbGlhYmxlLCBpbi1vcmRlciB0cmFuc3BvcnQgaXMgcmVxdWlyZWQs IGFuZCB0aGF0IHRoZSBsb3dlciBsYXllcnMgbXVzdA0KYWxsb3cNCiAgaWRlbnRpZmljYXRpb24g VExTIG1lc3NhZ2VzIGluIHRoZSBzYW1lIHNlc3Npb24gKGUuZy4gdGhlIDUtdHVwbGUgd2hlbg0K VENQIGlzIHVzZWQpLg0KDQotIEkgY2Fubm90IGZpbmQgYW55IHRleHQgZGVzY3JpYmluZyB0aGF0 IFRMUyAxLjMgb3V0cHV0cyBhIHN0cmVhbQ0KaWRlbnRpY2FsIHRvIHRoZSBpbnB1dA0KICBzdHJl YW0uIFRoZSBjdXJyZW50IHRleHQgb25seSBzdGF0ZXMgdGhhdCB0aGUgaW5wdXQgb24gdGhlIHNl bmRlciBzaWRlDQppcyBhcHBsaWNhdGlvbg0KICBtZXNzYWdlcy4gU2hvdWxkIHN0YXRlIHRoYXQg dGhlIFRMUyBpcyByZWxpYWJsZSBhbmQgaW4tb3JkZXIuDQoNCi0gVGhlIGFyZSBubyByZXF1aXJl bWVudHMgb24gdGhlIFRMUyBBUEkuIEkgdGhpbmsgdGhlIGZvbGxvd2luZyBzaG91bGQgYmUNCmFk ZGVkOg0KICAtIFNIQUxMIHN1cHBvcnQgYW4gZXhwb3J0ZXIgQVBJDQogIC0gU0hBTEwgc3VwcG9y dCBhbiBBUEkgYWxsb3dpbmcgYW4gYXBwbGljYXRpb24gdG8gZ2V0IGluZm9ybWF0aW9uDQpyZWdh cmRpbmcgdGhlIG5lZ290aWF0ZWQNCiAgICBjb25uZWN0aW9uLg0KICAtIFNIT1VMRCBzdXBwb3J0 IGFuIEFQSSBhbGxvd2luZyBhbiBhcHBsaWNhdGlvbiB0byBpbmZsdWVuY2UgdGhlDQpjb25uZWN0 aW9uIHRvIGJlDQogICAgbmVnb3RpYXRlZC4NCg0KLSBUTFMgMS4zIGFsc28gdXBkYXRlcyBSRkM1 MjQ2LCBidXQgSSBkb24ndCBrbm93IGlmIHlvdSBjYW4gYm90aCB1cGRhdGUNCmFuZCBvYnNvbGV0 ZS4NCiAgSWYgeW91IGhhdmUgdG8gY2hvb3NlLCBvYnNvbGV0ZSBpcyBiZXR0ZXIuDQoNCi0gU2Vj dGlvbiAxOiBUaGlzIGlzIHRoZSBvbmx5IHBsYWNlIGNoYW5uZWwgaXMgdXNlZCBpbiB0aGUgbWVh bmluZw0KY29ubmVjdGlvbi4gSSBzdWdnZXN0DQogICJjaGFubmVsIiAtPiAiY29ubmVjdGlvbiIN CiAgYXMgY29ubmVjdGlvbiBpcyB1c2VkIGluIHRoZSByZXN0IG9mIHRoZSBkb2N1bWVudC4NCg0K LSBTZWN0aW9uIDE6ICJUaGUgVExTIHN0YW5kYXJkLCBob3dldmVyLCBkb2VzIG5vdCBzcGVjaWZ5 IC4uLiBob3cgdG8NCmludGVycHJldCB0aGUNCiAgYXV0aGVudGljYXRpb24gY2VydGlmaWNhdGVz Ig0KDQogIEkgZG9uJ3QgdGhpcyBpcyByZWFsbHkgdHJ1ZSBhbnkgbW9yZSwgdGhlIGRyYWZ0IGhh cyBzaWduaWZpY2FudCB0ZXh0IG9uDQpjZXJ0aWZpY2F0ZXMuDQogIEkgc3VnZ2VzdCByZW1vdmlu ZyAiaG93IHRvIGludGVycHJldCB0aGUgYXV0aGVudGljYXRpb24gY2VydGlmaWNhdGVzDQpleGNo YW5nZWQiDQoNCi0gRmlndXJlIDEsIDQ6ICJwcmVfc2hhcmVkX2tleV9tb2RlcyIgLT4gInBza19r ZXlfZXhjaGFuZ2VfbW9kZXMiDQoNCi0gRmlndXJlIDEuICJTZXJ2ZXIgUGFyYW1zIiBub3QgaG9y aXpvbnRhbGx5IGFsaWduZWQgd2l0aCAiS2V5IEV4Y2giIGFuZA0KIkF1dGgiDQogIChub3Qgc3Vy ZSBpZiB0aGlzIGlzIGEgZmVhdHVyZSBvciBhIGJ1ZykuDQoNCi0gU2VjdGlvbiAyOiANCi0gIkNl cnRpZmljYXRlVmVyaWZ5OiAgYSBzaWduYXR1cmUgb3ZlciB0aGUgZW50aXJlIGhhbmRzaGFrZSAi DQogICJGaW5pc2hlZCA6ICBhIE1BQyBvdmVyIHRoZSBlbnRpcmUgaGFuZHNoYWtlICINCg0KICBO b3QgcmVhbGx5IHRydWUuIE1heWJlIGFkZCBzb21ldGhpbmcgbGlrZSAidG8gdGhpcyBwb2ludCIN Cg0KLSBTZWN0aW9uIDI6IFRoZSB0ZXh0IGJlbG93IEZpZ3VyZSAxIHNob3VsZCBtZW50aW9uDQpw c2tfa2V5X2V4Y2hhbmdlX21vZGVzLiBJdCB0YWxrcw0KICBhYm91dCBhbGwgb3RoZXIgbWVzc2Fn ZXMgYW5kIGV4dGVuc2lvbnMuDQoNCi0gU2VjdGlvbiAyLjI6IE9MRCAiUFNLcyBjYW4gYmUgdXNl ZCB3aXRoIChFQylESEUgZXhjaGFuZ2UiDQogICAgICAgICAgICAgICBORVcgIlBTS3MgU0hPVUxE IGJlIHVzZWQgd2l0aCAoRUMpREhFIGV4Y2hhbmdlIg0KDQotIFNlY3Rpb24gMi4zOiANCiAgIldo ZW4gUFNLcyBhcmUgcHJvdmlzaW9uZWQgb3V0IG9mIGJhbmQsIHRoZSBQU0sgaWRlbnRpdHkgYW5k IHRoZSBLREYgdG8NCmJlIHVzZWQgd2l0aA0KICAgdGhlIFBTSyBNVVNUIGFsc28gYmUgcHJvdmlz aW9uZWQuIg0KICAgDQogICBPTEQgImFuZCB0aGUgS0RGIHRvIGJlIHVzZWQiDQogICBORVcgImFu ZCB0aGUgSGFzaCBhbGdvcml0aG0gdG8gYmUgdXNlZCINCiAgIA0KICAgSSB0aGluayB0aGlzIGlz IGEgbGl0dGxlIHByb2JsZW1hdGljIGFzIGN1cnJlbnQgUFNLIHByb3Zpc2lvbmluZw0KbWVjaGFu aXNtcyBkbw0KICAgbm90IHByb3Zpc2lvbiBhIGhhc2ggYWxnb3JpdGhtLiBUaGlzIG1lYW5zIHRo YXQgdGhleSBuZWVkIHRvIGJlIHVwZGF0ZWQNCmJlZm9yZQ0KICAgVExTIDEuMyBjYW4gYmUgdXNl ZC4gT3RoZXJ3aXNlIHRoZSByaXNrIGlzIHRoYXQgb25lIGVuZHBvaW50IHVzZXMNClNIQS0yNTYg YW5kDQogICB0aGUgb3RoZXIgU0hBLTM4NC4gVG8gZW5hYmxlIFBTSyBzeXN0ZW1zIHRvIGRpcmVj dGx5IGFuZCBlYXNpbHkgdXBncmFkZQ0KdG8NCiAgIFRMUyAxLjMgSSBzdWdnZXN0IHRoZSBmb2xs b3dpbmcNCiAgIA0KICAgT0xEDQogICAiV2hlbiBQU0tzIGFyZSBwcm92aXNpb25lZCBvdXQgb2Yg YmFuZCwgdGhlIFBTSyBpZGVudGl0eSBhbmQgdGhlIEtERiB0bw0KYmUgdXNlZCB3aXRoDQogICB0 aGUgUFNLIE1VU1QgYWxzbyBiZSBwcm92aXNpb25lZC4iDQoNCiAgIE5FVw0KICAgIldoZW4gUFNL cyBhcmUgcHJvdmlzaW9uZWQgb3V0IG9mIGJhbmQsIHRoZSBQU0sgaWRlbnRpdHkgTVVTVCBhbHNv IGJlDQpwcm92aXNpb25lZCBhbmQNCiAgIHRoZSBIYXNoIGFsZ29yaXRobSB0byBiZSB1c2VkIFNI T1VMRCBiZSBwcm92aXNpb25lZC4gSWYgbm8gaGFzaA0KYWxnb3JpdGhtIGhhcyBiZWVuDQogICBw cm92aXNpb25lZCwgdGhlbiBTSEEtMjU2IFNIQUxMIGJlIHVzZWQuIg0KICAgDQogICBUaGlzIHdv dWxkIGFsc28gYWZmZWN0IDQuMi42Lg0KDQotIFNlY3Rpb24gMi4zOiAidGhlIGZvbGxvd2luZyBh ZGRpdGlvbmFsIGluZm9ybWF0aW9uIE1VU1QgYmUgcHJvdmlzaW9uZWQNCnRvIGJvdGggcGFydGll czoNCg0KICAgLSAgVGhlIEFwcGxpY2F0aW9uLUxheWVyIFByb3RvY29sIE5lZ290aWF0aW9uIChB TFBOKSBwcm90b2NvbCwgaWYgYW55DQogICAgICBpcyB0byBiZSB1c2VkDQoNCiAgIC0gIFRoZSBT ZXJ2ZXIgTmFtZSBJbmRpY2F0aW9uIChTTkkpLCBpZiBhbnkgaXMgdG8gYmUgdXNlZCINCg0KICBJ IHRoaW5rIHRoZXNlIHR3byBidWxsZXRzIGFwcGx5IHRvIEFMTCB1c2VzIG9mIFRMUy4gT3I/IEkg c3VnZ2VzdCBtb3ZpbmcNCnRvIGEgZ2VuZXJhbA0KICBzZWN0aW9uLg0KDQotIFNlY3Rpb24gMi4z OiAiMS4gIFRoaXMgZGF0YSBpcyBub3QgZm9yd2FyZCBzZWNyZXQsIGFzIGl0IGlzIGVuY3J5cHRl ZA0Kc29sZWx5IHVuZGVyIGtleXMNCiAgZGVyaXZlZCB1c2luZyB0aGUgb2ZmZXJlZCBQU0suIg0K DQogIFRoaXMgaXMgdHJ1ZSBmb3IgYWxsIHVzZXMgb2YgUFNLIHdpdGhvdXQgKEVDKURIRSBhbmQg bm90IG9ubHkgWmVyby1SVFQuDQpJIHN1Z2dlc3QNCiAgbW92aW5nIHRoaXMgdGV4dCB0byBhbm90 aGVyIG1vcmUgZ2VuZXJhbCBzZWN0aW9uLiBNYXliZSBpbiBTZWN0aW9uIDINCndoZW4gdGhlIHRo cmVlDQogIGJhc2ljIGtleSBleGNoYW5nZSBtb2RlcyBhcmUgZGlzY3Vzc2VkLg0KDQotIFNlY3Rp b24gMi4zOiBaZXJvLVJUVCB3aXRoIFBTSyBvYnRhaW5lZCBvdXQtb2YtYmFuZCBpcyBhIHNwZWNp YWwgY2FzZSBvZg0KICBaZXJvLVJUVCwgd2l0aCBpdHMgb3duIHJlcXVpcmVtZW50cyBhbmQgd2Fy bmluZ3MuIEkgdGhpbmsgaXQgc2hvdWxkIGJlDQptb3ZlZCB0byBpdHMNCiAgb3duIHN1YnN1YnNl Y3Rpb24gKDIuMy4xKS4NCg0KLSBTZWN0aW9uIDMuNTogImVudW0geyBlMSh2MSksIGUyKHYyKSwg Li4uICwgZW4odm4pIFtbLCAobildXSB9IFRlOyINCiAgVGhlIHZhcmlhYmxlICduJyBpcyB1c2Vk IGZvciB0d28gZGlmZmVyZW50IHB1cnBvc2VzLiBVc2UgbiwgbSBvcg0Kc29tZXRoaW5nLg0KDQot IFNlY3Rpb24gMy44OiBTYW1lIHRoaW5nIGhlcmUuIFRoZSB2YXJpYWJsZSAnbicgaXMgdXNlZCBm b3IgdHdvIGRpZmZlcmVudA0KcHVycG9zZXMuDQoNCi0gU2VjdGlvbiA0LjAgVGhlIGNhc2VzIGlu IEhhbmRzaGFrZSBkZWZpbml0aW9uIGluIHNvbWUgcmFuZG9tIG9yZGVyLg0KU2hvdWxkIGtlZXAg dGhlIHNhbWUNCiAgb3JkZXIgYXMgdGhlIEhhbmRzaGFrZVR5cGUgZGVmaW5pdGlvbi4NCg0KLSBT ZWN0aW9uIDQuMS4yICJJbmNsdWRpbmcgYSAiY29va2llIiBleHRlbnNpb24gaWYgb25lIHdhcyBw cm92aWRlZCBpbiB0aGUNCiAgSGVsbG9SZXRyeVJlcXVlc3QuIg0KICBDb3VsZCBzdGF0ZSB0aGF0 IHRoaXMgaXMgdGhlIEhlbGxvUmV0cnlSZXF1ZXN0IGNvb2tpZSBlY2hvZWQgYmFjay4NCiAgDQot IFNlY3Rpb24gNC4xLjMgSSBkb24ndCB0aGluayBTZXJ2ZXJIZWxsby5leHRlbnNpb25zIGNhbiBi ZSAwIGxlbmd0aCwgYnV0DQptYXliZSB0aGVyZSBpcw0KICBubyB3ZWxsIGRlZmluZWQgbWluaW11 bSBsZW5ndGguLi4NCg0KLSBTZWN0aW9uIDQuMS4zDQogIFNob3VsZCBzdGF0ZSB0aGF0IFNlcnZl ci5yYW5kb20gc2hhbGwgYmUgKHBzdWVkby0pcmFuZG9tLCBJIGRvbid0IHRoaW5rDQp0aGlzIGlz IHN0YXRlZA0KICAoZXhjZXB0IHRoYXQgdGhlIG5hbWUga2luZCBvZiBpbmRpY2F0ZXMgaXQpDQog IA0KICBPTEQ6ICJyYW5kb20gIFRoaXMgc3RydWN0dXJlIGlzIGdlbmVyYXRlZCBieSB0aGUgc2Vy dmVyIGFuZCBNVVNUIGJlDQogICAgICAgIGdlbmVyYXRlZCBpbmRlcGVuZGVudGx5IG9mIHRoZSBD bGllbnRIZWxsby5yYW5kb20uDQogIE5FVzogInJhbmRvbSAgMzIgYnl0ZXMgZ2VuZXJhdGVkIGJ5 IHRoZSBzZXJ2ZXIuIFRoZSBmaXJzdCAyNCBieXRlcyBhcmUNCmdlbmVyYXRlZCBieSBhDQogICAg ICAgc2VjdXJlIHJhbmRvbSBudW1iZXIgYW5kIE1VU1QgYmUgZ2VuZXJhdGVkIGluZGVwZW5kZW50 bHkgb2YgdGhlDQpDbGllbnRIZWxsby5yYW5kb20uDQoNCi0gU2VjdGlvbiA0LjEuMw0KICBPTEQg ImFzIGxvbmcgYXMgZXBoZW1lcmFsIGNpcGhlcnMgYXJlIHVzZWQiDQogIE5FVyAiYXMgbG9uZyBh cyBlcGhlbWVyYWwga2V5IGV4Y2hhbmdlIGFyZSB1c2VkIg0KDQogIEFzIHRoZSBlcGhlbWVyYWwg cGFydCBpcyBub3QgcGFydCBvZiB0aGUgY2lwaGVyIHN1aXRlcyBhbnltb3JlLg0KDQotIFNlY3Rp b24gNC4xLjMgIkl0IGRvZXMgbm90IHByb3ZpZGUgZG93bmdyYWRlIHByb3RlY3Rpb24gd2hlbiBz dGF0aWMgUlNBDQppcyB1c2VkLiINCiAgSSBkb24ndCBrbm93IHRoZSBkZXRhaWxzIG9mIFNlcnZl cktleUV4Y2hhbmdlLCBidXQgaXQgdGhpcyBub3QgdHJ1ZSBmb3INCm5vbi1ESEUgUFNLDQogIGFz IHdlbGw/DQoNCi0gU2VjdGlvbiA0LjIuNA0KICBJIGRvIG5vdCByZWFsbHkgdW5kZXJzdGFuZCB3 aHkgdGhlIHByaXZhdGVfdXNlIGRpdmlkZWQgYW5kIHJlc3RpY3RlZD8NCiAgSS5lLiBmZmRoZV9w cml2YXRlX3VzZSBhbmQgZWNkaGVfcHJpdmF0ZV91c2UuIEkgdGhpbmsgaXQgd291bGQgYmUNCnBy ZWZlcmFibGUgdG8ganVzdA0KICBoYXZlICJwcml2YXRlX3VzZSIgd2l0aG91dCBzcGVjaWZ5aW5n IHRoZSBleGFjdCB1c2UuIFdoZXJlIGRvIEkgZS5nLiBwdXQNCm15IHByaXZhdGUgdXNlDQogIFNJ REgsIGFuZCBMYXR0aWNlLWJhc2VkIGtleSBleGNoYW5nZSBpbmZvcm1hdGlvbi4gRmVlbHMgbGlr ZSB0aGlzIGlzIHRoZQ0KbmF0dXJhbCBwbGFjZSwNCiAgb3IgaXMgdGhlIGludGVudGlvbiB0aGF0 IGEgbmV3IGV4dGVuc2lvbiBpcyByZXF1aXJlZCBmb3IgUFFDPw0KDQotIFNlY3Rpb24gNC4yLjgN CiAgT0xEICJ0aGUgc2VydmVyIE1VU1QgaGF2ZSBhY2NlcHRlZCBhIFBTSyBjaXBoZXIgc3VpdGUi DQogIE9MRCAidGhlIHNlcnZlciBNVVNUIGhhdmUgYWNjZXB0ZWQgYSBQU0sga2V5IGV4Y2hhbmdl IG1vZGUiDQoNCi0gU2VjdGlvbiA1LjUgInVwIHRvIDJeMjQuNSBmdWxsLXNpemUgcmVjb3JkcyIN Cg0KICBJdCBpcyBub3Qgd2VsbC1kZWZpbmVkIG9uIGhvdyB0byBkbyB3aXRoIG5vbi1mdWxsLXNp emUgcmVjb3Jkcy4gSSBzdWdnZXN0DQogIA0KICBPTEQgInVwIHRvIDJeMjQuNSBmdWxsLXNpemUg cmVjb3JkcyINCiAgTkVXIOKAnHVwIHRvIDJeMjQuNSByZWNvcmRzIg0KDQotIFNlY3Rpb24gNS41 DQogIExpbWl0cyBhcmUgbmVlZGVkIGFsc28gZm9yIEFFUy1DQ00uIEl0IHNob3VsZCBhbHNvIGJl IHN0YXRlZCB0aGF0IG5ldw0Kc3BlY2lmaWNhdGlvbnMNCiAgZGVmaW5pbmcgbmV3IFRMUyBjaXBo ZXJzIFNIQUxMIHByb3ZpZGUgbG1pdHMgb24gdGhlIG51bWJlciBvZiByZWNvcmRzDQp0aGF0IGNh biBiZQ0KICBwcm90ZWN0ZWQgd2l0aCBhIGdpdmVuIGtleS4NCiAgDQogIEFzIGZhciBhcyBJIHVu ZGVyc3RhbmQgdGhlIGNvbmZpZGVudGlhbGl0eSBsaW1pdHMgZm9yIEFFUy1DQ00gKGFuZCBDUlQN CmFuZCBDQkMpIHdvdWxkDQogIGJlIHRoZSBzYW1lIGFzIGZvciBBRVMtR0NNLiBJIHN1Z2dlc3QN CiAgDQogIE9MRCAiRm9yIEFFUy1HQ00sIHVwIHRvIDJeMjQuNSBmdWxsLXNpemUgcmVjb3JkcyIN CiAgTkVXICJGb3IgQUVTLUdDTSBhbmQgQUVTLUNDTSwgdXAgdG8gMl4yNC41IHJlY29yZHMiDQog DQogIFRoZXNlIGxpbWl0cyBhcmUgcXVpdGUgaGFyZCwgYnV0IEkgdGhpbmsgdGhhdCBpcyBmaW5l IGFzIGl0IHNob3VsZCBub3QNCmJlIGEgcHJvYmxlbQ0KICB0byByZWtleSBmcmVxdWFudGx5Lg0K IA0KLSBTZWN0aW9uIDUuNSAiZm9yIEF1dGhlbnRpY2F0ZWQgRW5jcnlwdGlvbiAoQUUpIHNlY3Vy aXR5LiINCiAgSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gc3RhdGUgdGhhdCB0aGlzIGlzIGNvbmZp ZGVudGlhbGl0eSAoaW4gY29uc3RyYXN0DQp0byBpbnRlZ3JpdHkNCiAgb3Iga2V5IHJlY292ZXJ5 KS4gU3VnZ2VzdGlvbg0KICANCiAgT0xEICJmb3IgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIChB RSkgc2VjdXJpdHkuIg0KICBORVcgImZvciBhbiBjb25maWRlbnRpYWxpdHkgYXR0YWNrIg0KDQot IFNlY3Rpb24gOA0KICBUaGUgc2VudGVuY2VzICJJbiB0aGUgYWJzZW5jZSBvZiBhbiBhcHBsaWNh dGlvbiBwcm9maWxlIHN0YW5kYXJkDQpzcGVjaWZ5aW5nIG90aGVyd2lzZSINCiAgb25seSBhcHBs eSB0byBzb21lIHBhcnRzIG9mIFNlY3Rpb24gOC4gRS5nLiBpdCBhcHBsaWVzIHRvIGNpcGhlciBz dWl0ZXMNCmJ1dCBub3QgdG8gdGhlDQogIGRpZmZpZS1oZWxsbWFuIGdyb3Vwcy4gRmVlbHMgbGlr ZSB0aGlzIHNob3VsZCBhcHBseSB0byB0aGUgd2hvbGUNCnNlY3Rpb24uIEkgc3VnZ2VzdA0KICBy ZW1vdmluZyB0aGUgY3VycmVudCBvY2N1cmVuY2VzIG9mICIiSW4gdGhlIGFic2VuY2Ugb2YgYW4g YXBwbGljYXRpb24NCnByb2ZpbGUgc3RhbmRhcmQNCiAgc3BlY2lmeWluZyBvdGhlcndpc2UiIGFu ZCBhZGQgKGF0IHRoZSBzdGFydCBvZiBTZWN0aW9uIDguKQ0KDQogICJJbiB0aGUgYWJzZW5jZSBv ZiBhbiBhcHBsaWNhdGlvbiBwcm9maWxlIHN0YW5kYXJkIHNwZWNpZnlpbmcgb3RoZXJ3aXNlLA0K dGhlIGZvbGxvd2luZw0KICByZXF1aXJlbWVudHMgYXBwbHkiLg0KDQotIFNlY3Rpb24gOC4xIGFu ZCA4LjINCiAgVGhlIGhlYWRpbmcgc2F5cyAiTVRJIiBidXQgdGhlIHRleHQgYWxzbyBjb250YWlu cyBub24tbWFuZGF0b3J5IHRoaW5ncw0KKFNIT1VMRCkNCg0KICBJIHN1Z2dlc3QgY2hhbmdpbmcg Ik1USSIgdG8gIlJlcXVpcmVtZW50cyINCg0KLSBTZWN0aW9uIDguMQ0KICBUaGUgdGl0bGUgaXMg ImNpcGhlciBzdWl0ZXMiLCBidXQgdGhlIHNjb3BlIGlzIGJyb2FkZXIgKHNpZ25hdHVyZXMgYW5k DQprZXkNCiAgZXhjaGFuZ2UpLiBJIHN1Z2Vnc3QgY2hhbmdpbmcgdGhlIGhlYWRpbmcgdG8NCiAg DQogICJSZXF1aXJlbWVudHMgZm9yIGNpcGhlciBzdWl0ZXMsIHNpZ25hdHVyZXMsIGFuZCBncm91 cHMiDQoNCi0gU2VjdGlvbiA4LjIgVGhpcyBzZWN0aW9uIHNlZW1zIHRvIGZvcmdldCBwc2tfa2V5 X2V4Y2hhbmdlX21vZGVzLiBJZg0KcHJlX3NoYXJlZF9rZXkgaXMNCiAgbWFuZGF0b3J5IHRoZW4g cHNrX2tleV9leGNoYW5nZV9tb2RlcyBzaG91bGQgYmUgdG8uDQoNCi0gU2VjdGlvbiA5OiBTaG91 bGQgbWVudGlvbiB0aGF0IGFuIGF0dGFja2VyIGF0IGFueSBwb2ludCBjYW4gdGVybWluYXRlDQp0 aGUgc2Vzc2lvbiBieQ0KICBzZW5kaW5nIGEgc2luZ2xlIG1hbGZvcm1lZCBwYWNrZXQuIFRoaXMg dGVybWluYXRpb24gZmVhdHVyZSBpcyBib3RoDQpwb3NpdGl2ZSBhbmQNCiAgbmVnYXRpdmUuDQoN Ci0gU2VjdGlvbiAxMS4yOiBbUkZDNDI3OV0gaXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIGJ1 dCBuZXZlciByZWZlcnJlZA0KdG8uDQoNCi0gU2VjdGlvbiBBLjQgIlRMUyAxLjIgYW5kIGxvd2Vy IGNpcGhlciBzdWl0ZXMgY2Fubm90IGJlIHVzZWQgd2l0aCBUTFMNCjEuMy4iDQogIEkgY2Fubm90 IGZpbmQgYW55IHRleHQgaW4gdGhlIGRyYWZ0IHN0YXRpbm4gdGhhdCB5b3UgY2FuIG5lZ290aWF0 ZSBUTFMNCjEuMiBjaXBoZXJzdWl0ZXMNCiAgaW4gVExTIDEuMywgSSB0aGluayB0aGlzIHNob3Vs ZCBiZSBzdGF0ZWQuDQogIA0KICBPTEQ6ICJUTFMgMS4yIGFuZCBsb3dlciBjaXBoZXIgc3VpdGVz IGNhbm5vdCBiZSB1c2VkIHdpdGggVExTIDEuMy4iDQogIE5FVzogIlRMUyAxLjIgYW5kIGxvd2Vy IGNpcGhlciBzdWl0ZXMgY2Fubm90IGJlIHVzZWQgd2l0aCBUTFMgMS4zLCBidXQNCmNhbiBiZQ0K ICAgICAgICBuZWdvdGlhdGVkIGluIGEgVExTIDEuMyBDbGllbnQgSGVsbG8uIg0KDQotIFNlY3Rp b24gRC4yDQogIE9MRCAid2Vha2VyIHRoYW4gMjA0OC1iaXQgUlNBIG9yIDIyNC1iaXQgRUNEU0Eg YXJlIG5vdCBhcHByb3ByaWF0ZSINCiAgT0xEICJ3ZWFrZXIgdGhhbiAyMDQ4LWJpdCBSU0EsIDIy NC1iaXQgRUNEU0EsIG9yIDEyOC1iaXQgUFNLIGFyZSBub3QNCmFwcHJvcHJpYXRlIg0KDQotIFNl Y3Rpb24gRC4yICJUaGUgcmVhZGVyIHNob3VsZCByZWZlciB0byB0aGUgZm9sbG93aW5nIHJlZmVy ZW5jZXMgZm9yDQphbmFseXNpcyBvZg0KICB0aGUgVExTIHJlY29yZCBsYXllci4iDQogICANCiAg Tm8gcmVmZXJlbmNlcyBnaXZlbi4NCg0KIA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpKT0hOIE1BVFRTU09ODQpNU2Mg RW5naW5lZXJpbmcgUGh5c2ljcywgTVNjIEJ1c2luZXNzIEFkbWluaXN0cmF0aW9uIGFuZCBFY29u b21pY3MNCkVyaWNzc29uIElFVEYgU2VjdXJpdHkgQ29vcmRpbmF0b3INClNlbmlvciBSZXNlYXJj aGVyLCBTZWN1cml0eQ0KDQo= From nobody Sat Nov 19 20:21:13 2016 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 A09B3129547 for ; Sat, 19 Nov 2016 20:21:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 hxFt5JKYiXIW for ; Sat, 19 Nov 2016 20:21:09 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC171294B5 for ; Sat, 19 Nov 2016 20:21:09 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 388CF433405; Sun, 20 Nov 2016 04:21:08 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 22725433401; Sun, 20 Nov 2016 04:21:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479615668; bh=RD49pxBjV8bD1SXz970NwBjPZPf8YHQXcDyHsVnGdWc=; l=1726; h=From:To:Date:References:In-Reply-To:From; b=Xv13Fef81+dPS3QWaMCHxGpXe5DRMvH1Eudk4RehVrXBqGCwZqIaBARApUtLA+LId VB8ckrA2m6qhmMkNhotVOYI3NTPiziBYT1LXkgwessf/45E9u7adlLKDRwXdbEAt+a wxqYtv4fnVvK6MZ9QwGJruykcVqs+Kefb2ayfvMY= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 1EC271FC88; Sun, 20 Nov 2016 04:21:08 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sat, 19 Nov 2016 23:21:07 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Sat, 19 Nov 2016 23:21:07 -0500 From: "Salz, Rich" To: Sean Turner , "" Thread-Topic: [TLS] WGLC for draft-ietf-tls-rfc4492bis Thread-Index: AQHSQh6Z9X1Hg0mzJ0aKXLkuEjb/46DhRi7Q Date: Sun, 20 Nov 2016 04:21:07 +0000 Message-ID: <7462904085cc4a94914298af81157031@usma1ex-dag1mb1.msg.corp.akamai.com> References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> In-Reply-To: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.40.75] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 20 Nov 2016 04:21:11 -0000 SW4gQ1VSRExFIHRoaXMgd2Vlaywgd2UgaGFkIGNvbnNlbnN1cyAodG8gYmUgY29uZmlybWVkIG9u IHRoZSBsaXN0LCBvZiBjb3Vyc2UpIHRoYXQNCglTaWduYXR1cmUgY29udGV4dHMgd2VyZSBjcmVh dGVkIGluIHRoZSBUTFMgYXJlbmEsIHdlIGFsbCB0aG91Z2h0IHdlIG5lZWRlZCB0aGVtIGluIG90 aGVyIGFyZWFzLCBhbmQgd2UgZG9uJ3QsIHRoZXJlZm9yZSBhbGwgQ1VSRExFIGRvY3VtZW50cyBm b3IgdGhvc2Ugb3RoZXIgYXJlYXMgd2lsbCBzcGVjaWZ5IGEgemVyby1sZW5ndGggY29udGV4dC4N Cg0KRldJVy4NCg0KSSBhZ3JlZSB3aXRoIFlvYXYncyBtZXNzYWdlLCBmb3IgdGhlIHJlYXNvbnMg aGUgc3RhdGVzLg0KDQotLSAgDQpTZW5pb3IgQXJjaGl0ZWN0LCBBa2FtYWkgVGVjaG5vbG9naWVz DQpNZW1iZXIsIE9wZW5TU0wgRGV2IFRlYW0NCklNOiByaWNoc2FsekBqYWJiZXIuYXQgVHdpdHRl cjogUmljaFNhbHoNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFNl YW4gVHVybmVyIFttYWlsdG86c2VhbkBzbjNyZC5jb21dDQo+IFNlbnQ6IEZyaWRheSwgTm92ZW1i ZXIgMTgsIDIwMTYgNjo1NiBQTQ0KPiBUbzogPHRsc0BpZXRmLm9yZz4NCj4gU3ViamVjdDogW1RM U10gV0dMQyBmb3IgZHJhZnQtaWV0Zi10bHMtcmZjNDQ5MmJpcw0KPiANCj4gQWxsLA0KPiANCj4g VGhpcyBpcyBhIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGZvciB0aGUg4oCcNDQ5MmJpcyB0byBT dGFuZGFyZHMgVHJhY2siIGRyYWZ0DQo+IGF2YWlsYWJsZSBAIGh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi10bHMtcmZjNDQ5MmJpcy8uICBQbGVhc2UNCj4gcmV2aWV3 IHRoZSBkb2N1bWVudCBhbmQgc2VuZCB5b3VyIGNvbW1lbnRzIHRvIHRoZSBsaXN0IGJ5IDkgRGVj ZW1iZXINCj4gMjAxNi4NCj4gDQo+IE5vdGUgdGhhdCB3ZSBhcmUgcGFydGljdWxhcmx5IGludGVy ZXN0aW5nIGluIHRoZSBpc3N1ZSBZb2F2IHJhaXNlcyBpbiB0aGUNCj4gZm9sbG93aW5nIG1lc3Nh Z2U6DQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvdGxzLzhFYzdqUXFM cl8zRnJ2UWZ1Y2xsbGZvektaaw0KPiANCj4gVGhhbmtzLA0KPiBKJlMNCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVExTIG1haWxpbmcgbGlzdA0K PiBUTFNAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 bHMNCg== From nobody Sun Nov 20 02:22:50 2016 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 9175D1294C1 for ; Sun, 20 Nov 2016 02:22:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKHnFsC-_3Jt for ; Sun, 20 Nov 2016 02:22:48 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 EF7EF129499 for ; Sun, 20 Nov 2016 02:22:47 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g23so102037014wme.1 for ; Sun, 20 Nov 2016 02:22:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=4yJqqjBJqkJbJUSwGyQRhZRvBpyheW+quUzjCwkAVe4=; b=F2dV7AmNWvMmuOhX7dbBWjNVRm1VXcaW5NOpWm/KkXo90rf/nQpncJwJ3QViTX4EIk 4T1tPCiIN9n164kTEXde6W2I8bLNE2keeGD3asCqlw5sAW8mBTvLrhXIhwklDaM9rZ4I P1wTYNgr2G2QVVQvLAMtfE1vSqQWpo1kahWH9dw0wgEOInRtXiw5RLxk5F1peSwl5v9+ ZzkZ7iz/yoJ+zEW2BZ8LgQXobEh12cfDf9M8aIaubCfjMrKpESKzAJEIFC9/Uj29LPuU m0svstiyflLihzxLZq7ya0UVh4iXgYShRRP8hfU2IpaU5CMmwNbBI/bjdevo/PiRMojP Cu9w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=4yJqqjBJqkJbJUSwGyQRhZRvBpyheW+quUzjCwkAVe4=; b=k4mm1Lmoct/Pgd73lLU5wdfz41wwL/9mMmyqXiXbz2BToAoqA0RP2bYFJbZcXr2XB/ u3IqWhArwDIKbdZah3lLIFRTG+v2RK5RODzIepenLX50v6NsLXiRiKcqH+ZZAnaO2ift XRFPxFNKwW6bXe1bWblzHk3pWRmRpl68a+QvHrXSldPESuMO0Xr2uJuu1UwVwKesYiI6 aBliC6YOMSKQ5OY+6TfMJSGBRWbIH33fSaVTDQnAqYhrXv/zlyev/eVdotnUGqUP9txx srh9DzXHryayhvMZY15KAMCN1v0DbmWEj19luUsxClgzZzRIuML5hAuVwhWOLgNmFShj qkfg== X-Gm-Message-State: AKaTC00VcVqBxrnyb2yvyOdhgYFeXmoHC4Oub2SWn7u+mKtndkye8naZnKqUkwQ3itEJGw== X-Received: by 10.28.150.75 with SMTP id y72mr8003120wmd.47.1479637366324; Sun, 20 Nov 2016 02:22:46 -0800 (PST) Received: from [172.24.248.54] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id i2sm18659688wjx.44.2016.11.20.02.22.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2016 02:22:45 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Message-Id: <4DF30312-1A1C-4F11-9424-0412E5A52E6B@gmail.com> Date: Sun, 20 Nov 2016 12:21:43 +0200 To: "" X-Mailer: Apple Mail (2.3251) Archived-At: Subject: [TLS] Re-use and export of DH shares X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 20 Nov 2016 10:22:49 -0000 Hi. I=E2=80=99ve created a PR for TLS 1.3 https://github.com/tlswg/tls13-spec/pull/768 It adds a subsection to the Security Considerations section. It = discusses key reuse (do it carefully or do it not). It has the "don't do this or this grape juice might ferment" weasel = words suggested by someone at the meeting. Yoav From nobody Sun Nov 20 05:10:56 2016 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 5106B129653 for ; Sun, 20 Nov 2016 05:10:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 J0h_WJ2qU06n for ; Sun, 20 Nov 2016 05:10:52 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560D8129501 for ; Sun, 20 Nov 2016 05:10:52 -0800 (PST) X-AuditID: c1b4fb25-aefff70000007ee2-f1-5831a0d87f5f Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.183.21]) by (Symantec Mail Security) with SMTP id 7F.44.32482.8D0A1385; Sun, 20 Nov 2016 14:10:50 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.62]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.03.0319.002; Sun, 20 Nov 2016 14:10:48 +0100 From: John Mattsson To: "TLS@ietf.org" Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 Thread-Index: AQHSL/2+2v4l5+5kKUiyJ4qNLpCCr6DXocKAgAAe1ICAALIggIAI7NsAgAElk4A= Date: Sun, 20 Nov 2016 13:10:48 +0000 Message-ID: References: <13C3DBCF-2609-4560-A194-1FA422BE7EEE@akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="utf-8" Content-ID: <7CCF42A1DA94AC419E574924B2AC3FDA@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpnkeLIzCtJLcpLzFFi42KZGbFdVPfWAsMIgzlPlC0+ne9idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqb1x9kL9mVXHHkd28B4J6OLkZNDQsBEYtK5JtYuRi4OIYF1 jBIrtuxkgXAWM0o8PviQHaSKTcBAYu6eBrYuRg4OEQFFiU+fs0HCwgJuEltXLGADsUUE3CX2 n93ICmH7SZy4MZsZxGYRUJW4OH0OI4jNK2Au0bdwFTPE/LVMEhM3N4MlOAUsJFZtnQnWzCgg JvH91BomEJtZQFzi1pP5TBCXCkgs2XOeGcIWlXj5+B8ryD2iAnoSa+6HQYSVJNYe3s4CEmYW 0JRYv0sfYoq1xL+TDawQtqLElG6Ir3gFBCVOznzCMoFRbBaSZbMQumch6Z6FpHsWku4FjKyr GEWLU4uTctONjPVSizKTi4vz8/TyUks2MQKj5+CW36o7GC+/cTzEKMDBqMTDW3DTIEKINbGs uDL3EKMEB7OSCO/T+YYRQrwpiZVVqUX58UWlOanFhxilOViUxHnNVt4PFxJITyxJzU5NLUgt gskycXBKNTD2zJ2cvCmgI9M3SKvg4ufqzV/5yzfrJp7z3Zn9PlTmyO9TXmuvfFx7sjT3Rp/S TuOle4S4r06WPv2/NPtDwqKer6ZbXPdc3VQcvkNhyrTz107e9fr00Y3R8evd5UmiNjcn78h8 mewS3O427YL7jPDQt7pNq7bG9n5aLL/hZuNv1czDGm9jtU6WK7EUZyQaajEXFScCAD2KpeOa AgAA Archived-At: Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 20 Nov 2016 13:10:55 -0000 KFRoaXMgaXMgdGhlIHNhbWUgY29tbWVudHMgYXMgeWVzdGVyZGF5LCBqdXN0IHJlc2VuZGluZyB0 aGVtIGFzIG15IG1haWwNCmNsaWVudCB0dXJuZWQgbXkgdGV4dCBpbnRvIGFuIHVucmVhZGFibGUg bWVzcywgaG9wZWZ1bGx5IHRoaXMgaXMgYmV0dGVyKS4NCg0KDQpIaSwNCg0KVmVyeSB3ZWxsIHdy aXR0ZW4gZHJhZnQgYW5kIGFuIGV4Y2VsbGVudCBwcm90b2NvbC4gVGhlIHRoaW5ncyBJIGhhdmUg Zm91bmQNCmlzIG1vc3RseSBlZGl0b3JpYWwuIEkgdGhpbmsgaXTigJlzIHJlYWR5LiBJIHdpbGwg dHJ5IHRvIG1ha2Ugc3VyZSB0aGF0IDNHUFANCmFscmVhZHkgbmV4dCB5ZWFyIG1hbmRhdGVzIHN1 cHBvcnQgb2YgYm90aCBUTFMgMS4zIGFuZCBEVExTIDEuMyBpbiBhbGwgdGhlDQpwbGFjZXMgdGhl eSB1c2UgKEQpVExTLg0KDQpDaGVlcnMsDQpKb2huDQoNCg0KLSBJIGNhbm5vdCBmaW5kIGFueSB0 ZXh0IGRlc2NyaWJpbmcgdGhlIHJlcXVpcmVtZW50cyBUTFMgMS4zIHB1dCBvbiB0aGUNCiAgbG93 ZXIgbGF5ZXJzLiBJbiBmYWN0IHRoZSBvbmx5IHRleHQgSSBjYW4gZmluZCBpcyAid2hpY2ggbWln aHQgYmUgaGlkZGVuDQogIGJ5IFRDUCIuIEkgZG9uJ3Qga25vdyBpZiB0aGUgZHJhZnQgc2hvdWxk IG1hbmRhdGUgVENQIG9yIG5vdCwgYnV0DQogIG90aGVyd2lzZSBpdCBzaG91bGQgYmUgc3RhdGVk IHRoYXQgcmVsaWFibGUsIGluLW9yZGVyIHRyYW5zcG9ydCBpcw0KICByZXF1aXJlZCwgYW5kIHRo YXQgdGhlIGxvd2VyIGxheWVycyBtdXN0IGFsbG93IGlkZW50aWZpY2F0aW9uIFRMUw0KICBtZXNz YWdlcyBpbiB0aGUgc2FtZSBzZXNzaW9uIChlLmcuIHRoZSA1LXR1cGxlIHdoZW4gVENQIGlzIHVz ZWQpLg0KDQotIEkgY2Fubm90IGZpbmQgYW55IHRleHQgZGVzY3JpYmluZyB0aGF0IFRMUyAxLjMg b3V0cHV0cyBhIHN0cmVhbSBpZGVudGljYWwNCiAgdG8gdGhlIGlucHV0c3RyZWFtLiBUaGUgY3Vy cmVudCB0ZXh0IG9ubHkgc3RhdGVzIHRoYXQgdGhlIGlucHV0IG9uIHRoZQ0KICBzZW5kZXIgc2lk ZSBpcyBhcHBsaWNhdGlvbiBtZXNzYWdlcy4gU2hvdWxkIHN0YXRlIHRoYXQgdGhlIFRMUyBpcw0K ICByZWxpYWJsZSBhbmQgaW4tb3JkZXIuDQoNCi0gVGhlIGFyZSBubyByZXF1aXJlbWVudHMgb24g dGhlIFRMUyBBUEkuIEkgdGhpbmsgdGhlIGZvbGxvd2luZyBzaG91bGQgYmUNCiAgYWRkZWQ6DQog IC0gU0hBTEwgc3VwcG9ydCBhbiBleHBvcnRlciBBUEkNCiAgLSBTSEFMTCBzdXBwb3J0IGFuIEFQ SSBhbGxvd2luZyBhcHBsaWNhdGlvbiB0byBnZXQgaW5mb3JtYXRpb24gcmVnYXJkaW5nDQogICAg dGhlIG5lZ290aWF0ZWQgY29ubmVjdGlvbi4NCiAgLSBTSE9VTEQgc3VwcG9ydCBhbiBBUEkgYWxs b3dpbmcgYXBwbGljYXRpb24gdG8gaW5mbHVlbmNlIHRoZSBjb25uZWN0aW9uDQogICAgdG8gYmUg bmVnb3RpYXRlZC4NCg0KLSBUTFMgMS4zIGFsc28gdXBkYXRlcyBSRkM1MjQ2LCBidXQgSSBkb24n dCBrbm93IGlmIHlvdSBjYW4gYm90aCB1cGRhdGUgYW5kDQogIG9ic29sZXRlLiBJZiB5b3UgaGF2 ZSB0byBjaG9vc2UsIG9ic29sZXRlIGlzIGJldHRlci4NCg0KLSBTZWN0aW9uIDE6IFRoaXMgaXMg dGhlIG9ubHkgcGxhY2UgY2hhbm5lbCBpcyB1c2VkIGluIHRoZSBtZWFuaW5nDQogIGNvbm5lY3Rp b24uIEkgc3VnZ2VzdCAiY2hhbm5lbCIgLT4gImNvbm5lY3Rpb24iIGFzIGNvbm5lY3Rpb24gaXMg dXNlZCBpbg0KICB0aGUgcmVzdCBvZiB0aGUgZG9jdW1lbnQuDQoNCi0gU2VjdGlvbiAxOiAiVGhl IFRMUyBzdGFuZGFyZCwgaG93ZXZlciwgZG9lcyBub3Qgc3BlY2lmeSAuLi4gaG93IHRvDQogIGlu dGVycHJldCB0aGUgYXV0aGVudGljYXRpb24gY2VydGlmaWNhdGVzIg0KDQogIEkgZG9uJ3QgdGhp cyBpcyByZWFsbHkgdHJ1ZSBhbnkgbW9yZSwgdGhlIGRyYWZ0IGhhcyBzaWduaWZpY2FudCB0ZXh0 IG9uDQogIGNlcnRpZmljYXRlcy4gSSBzdWdnZXN0IHJlbW92aW5nICJob3cgdG8gaW50ZXJwcmV0 IHRoZSBhdXRoZW50aWNhdGlvbg0KICBjZXJ0aWZpY2F0ZXMgZXhjaGFuZ2VkIg0KDQotIEZpZ3Vy ZSAxLCA0OiAicHJlX3NoYXJlZF9rZXlfbW9kZXMiIC0+ICJwc2tfa2V5X2V4Y2hhbmdlX21vZGVz Ig0KDQotIEZpZ3VyZSAxLiAiU2VydmVyIFBhcmFtcyIgbm90IGhvcml6b250YWxseSBhbGlnbmVk IHdpdGggIktleSBFeGNoIiBhbmQNCiAgIkF1dGgiIChub3Qgc3VyZSBpZiB0aGlzIGlzIGEgZmVh dHVyZSBvciBhIGJ1ZykuDQoNCi0gU2VjdGlvbiAyOiANCiAgIkNlcnRpZmljYXRlVmVyaWZ5OiAg YSBzaWduYXR1cmUgb3ZlciB0aGUgZW50aXJlIGhhbmRzaGFrZSAiDQogICJGaW5pc2hlZCA6ICBh IE1BQyBvdmVyIHRoZSBlbnRpcmUgaGFuZHNoYWtlICINCg0KICBOb3QgcmVhbGx5IHRydWUuIE1h eWJlIGFkZCBzb21ldGhpbmcgbGlrZSAidG8gdGhpcyBwb2ludCINCg0KLSBTZWN0aW9uIDI6IFRo ZSB0ZXh0IGJlbG93IEZpZ3VyZSAxIHNob3VsZCBtZW50aW9uIHBza19rZXlfZXhjaGFuZ2VfbW9k ZXMuDQogIEl0IHRhbGtzIGFib3V0IGFsbCBvdGhlciBtZXNzYWdlcyBhbmQgZXh0ZW5zaW9ucy4N Cg0KLSBTZWN0aW9uIDIuMjogT0xEICJQU0tzIGNhbiBiZSB1c2VkIHdpdGggKEVDKURIRSBleGNo YW5nZSINCiAgICAgICAgICAgICAgIE5FVyAiUFNLcyBTSE9VTEQgYmUgdXNlZCB3aXRoIChFQylE SEUgZXhjaGFuZ2UiDQoNCi0gU2VjdGlvbiAyLjM6IA0KICAiV2hlbiBQU0tzIGFyZSBwcm92aXNp b25lZCBvdXQgb2YgYmFuZCwgdGhlIFBTSyBpZGVudGl0eSBhbmQgdGhlIEtERiB0bw0KICBiZSB1 c2VkIHdpdGggdGhlIFBTSyBNVVNUIGFsc28gYmUgcHJvdmlzaW9uZWQuIg0KDQogIE9MRCAiYW5k IHRoZSBLREYgdG8gYmUgdXNlZCINCiAgTkVXICJhbmQgdGhlIEhhc2ggYWxnb3JpdGhtIHRvIGJl IHVzZWQiDQogIA0KICBJIHRoaW5rIHRoaXMgaXMgYSBsaXR0bGUgcHJvYmxlbWF0aWMgYXMgY3Vy cmVudCBQU0sgcHJvdmlzaW9uaW5nDQogIG1lY2hhbmlzbXMgZG8gbm90IHByb3Zpc2lvbiBhIGhh c2ggYWxnb3JpdGhtLiBUaGlzIG1lYW5zIHRoYXQgdGhleSBuZWVkDQogIHRvIGJlIHVwZGF0ZWQg YmVmb3JlIFRMUyAxLjMgY2FuIGJlIHVzZWQuIE90aGVyd2lzZSB0aGUgcmlzayBpcyB0aGF0IG9u ZQ0KICBlbmRwb2ludCB1c2VzIFNIQS0yNTYgYW5kIHRoZSBvdGhlciBTSEEtMzg0LiBUbyBlbmFi bGUgUFNLIHN5c3RlbXMgdG8NCiAgZGlyZWN0bHkgYW5kIGVhc2lseSB1cGdyYWRlIHRvIFRMUyAx LjMgSSBzdWdnZXN0IHRoZSBmb2xsb3dpbmcNCg0KICBPTEQNCiAgIldoZW4gUFNLcyBhcmUgcHJv dmlzaW9uZWQgb3V0IG9mIGJhbmQsIHRoZSBQU0sgaWRlbnRpdHkgYW5kIHRoZSBLREYgdG8NCiAg YmUgdXNlZCB3aXRoIHRoZSBQU0sgTVVTVCBhbHNvIGJlIHByb3Zpc2lvbmVkLiINCg0KICBORVcN CiAgIldoZW4gUFNLcyBhcmUgcHJvdmlzaW9uZWQgb3V0IG9mIGJhbmQsIHRoZSBQU0sgaWRlbnRp dHkgTVVTVCBhbHNvIGJlDQogIHByb3Zpc2lvbmVkIGFuZCB0aGUgSGFzaCBhbGdvcml0aG0gdG8g YmUgdXNlZCBTSE9VTEQgYmUgcHJvdmlzaW9uZWQuIElmDQogIG5vIGhhc2ggYWxnb3JpdGhtIGhh cyBiZWVuIHByb3Zpc2lvbmVkLCB0aGVuIFNIQS0yNTYgU0hBTEwgYmUgdXNlZC4iDQogIA0KICBU aGlzIHdvdWxkIGFsc28gYWZmZWN0IDQuMi42Lg0KDQotIFNlY3Rpb24gMi4zOiAidGhlIGZvbGxv d2luZyBhZGRpdGlvbmFsIGluZm9ybWF0aW9uIE1VU1QgYmUgcHJvdmlzaW9uZWQgdG8NCiAgYm90 aCBwYXJ0aWVzOg0KDQogICAtICBUaGUgQXBwbGljYXRpb24tTGF5ZXIgUHJvdG9jb2wgTmVnb3Rp YXRpb24gKEFMUE4pIHByb3RvY29sLCBpZiBhbnkNCiAgICAgIGlzIHRvIGJlIHVzZWQNCg0KICAg LSAgVGhlIFNlcnZlciBOYW1lIEluZGljYXRpb24gKFNOSSksIGlmIGFueSBpcyB0byBiZSB1c2Vk Ig0KDQogIEkgdGhpbmsgdGhlc2UgdHdvIGJ1bGxldHMgYXBwbHkgdG8gQUxMIHVzZXMgb2YgVExT LiBPcj8gSSBzdWdnZXN0IG1vdmluZw0KICB0byBhIGdlbmVyYWwgc2VjdGlvbi4NCg0KLSBTZWN0 aW9uIDIuMzogIjEuICBUaGlzIGRhdGEgaXMgbm90IGZvcndhcmQgc2VjcmV0LCBhcyBpdCBpcyBl bmNyeXB0ZWQNCiAgc29sZWx5IHVuZGVyIGtleXMgZGVyaXZlZCB1c2luZyB0aGUgb2ZmZXJlZCBQ U0suIg0KDQogIFRoaXMgaXMgdHJ1ZSBmb3IgYWxsIHVzZXMgb2YgUFNLIHdpdGhvdXQgKEVDKURI RSBhbmQgbm90IG9ubHkgWmVyby1SVFQuIEkNCiAgc3VnZ2VzdCBtb3ZpbmcgdGhpcyB0ZXh0IHRv IGFub3RoZXIgbW9yZSBnZW5lcmFsIHNlY3Rpb24uIE1heWJlIGluDQogIFNlY3Rpb24gMiB3aGVu IHRoZSB0aHJlZSBiYXNpYyBrZXkgZXhjaGFuZ2UgbW9kZXMgYXJlIGRpc2N1c3NlZC4NCg0KLSBT ZWN0aW9uIDIuMzogWmVyby1SVFQgd2l0aCBQU0sgb2J0YWluZWQgb3V0LW9mLWJhbmQgaXMgYSBz cGVjaWFsIGNhc2Ugb2YNCiAgWmVyby1SVFQsIHdpdGggaXRzIG93biByZXF1aXJlbWVudHMgYW5k IHdhcm5pbmdzLiBJIHRoaW5rIGl0IHNob3VsZCBiZQ0KICBtb3ZlZCB0byBpdHMgb3duIHN1YnN1 YnNlY3Rpb24gKDIuMy4xKS4NCg0KLSBTZWN0aW9uIDMuNTogImVudW0geyBlMSh2MSksIGUyKHYy KSwgLi4uICwgZW4odm4pIFtbLCAobildXSB9IFRlOyINCiAgVGhlIHZhcmlhYmxlICduJyBpcyB1 c2VkIGZvciB0d28gZGlmZmVyZW50IHB1cnBvc2VzLiBVc2UgbiwgbSBvcg0KICBzb21ldGhpbmcu DQoNCi0gU2VjdGlvbiAzLjg6IFNhbWUgdGhpbmcgaGVyZS4gVGhlIHZhcmlhYmxlICduJyBpcyB1 c2VkIGZvciB0d28gZGlmZmVyZW50DQogIHB1cnBvc2VzLg0KDQotIFNlY3Rpb24gNC4wIFRoZSBj YXNlcyBpbiBIYW5kc2hha2UgZGVmaW5pdGlvbiBpbiBzb21lIHJhbmRvbSBvcmRlci4NCiAgU2hv dWxkIGtlZXAgdGhlIHNhbWUgb3JkZXIgYXMgdGhlIEhhbmRzaGFrZVR5cGUgZGVmaW5pdGlvbi4N Cg0KLSBTZWN0aW9uIDQuMS4yICJJbmNsdWRpbmcgYSAiY29va2llIiBleHRlbnNpb24gaWYgb25l IHdhcyBwcm92aWRlZCBpbiB0aGUNCiAgSGVsbG9SZXRyeVJlcXVlc3QuIg0KICBDb3VsZCBzdGF0 ZSB0aGF0IHRoaXMgaXMgdGhlIEhlbGxvUmV0cnlSZXF1ZXN0IGNvb2tpZSBlY2hvZWQgYmFjay4N Cg0KLSBTZWN0aW9uIDQuMS4zIEkgZG9uJ3QgdGhpbmsgU2VydmVySGVsbG8uZXh0ZW5zaW9ucyBj YW4gYmUgMCBsZW5ndGgsIGJ1dA0KICBtYXliZSB0aGVyZSBpcyBubyB3ZWxsIGRlZmluZWQgbWlu aW11bSBsZW5ndGguLi4NCg0KLSBTZWN0aW9uIDQuMS4zDQogIFNob3VsZCBzdGF0ZSB0aGF0IFNl cnZlci5yYW5kb20gc2hhbGwgYmUgKHBzdWVkby0pcmFuZG9tLCBJIGRvbid0IHRoaW5rDQogIHRo aXMgaXMgc3RhdGVkIChleGNlcHQgdGhhdCB0aGUgbmFtZSBraW5kIG9mIGluZGljYXRlcyBpdCkN CiAgDQogIE9MRDogInJhbmRvbSAgVGhpcyBzdHJ1Y3R1cmUgaXMgZ2VuZXJhdGVkIGJ5IHRoZSBz ZXJ2ZXIgYW5kIE1VU1QgYmUNCiAgICAgICAgZ2VuZXJhdGVkIGluZGVwZW5kZW50bHkgb2YgdGhl IENsaWVudEhlbGxvLnJhbmRvbS4NCiAgTkVXOiAicmFuZG9tICAzMiBieXRlcyBnZW5lcmF0ZWQg YnkgdGhlIHNlcnZlci4gVGhlIGZpcnN0IDI0IGJ5dGVzIGFyZQ0KICAgICAgIGdlbmVyYXRlZCBi eSBhIHNlY3VyZSByYW5kb20gbnVtYmVyIGFuZCBNVVNUIGJlIGdlbmVyYXRlZA0KICAgICAgIGlu ZGVwZW5kZW50bHkgb2YgdGhlIENsaWVudEhlbGxvLnJhbmRvbS4NCg0KLSBTZWN0aW9uIDQuMS4z DQogIE9MRCAiYXMgbG9uZyBhcyBlcGhlbWVyYWwgY2lwaGVycyBhcmUgdXNlZCINCiAgTkVXICJh cyBsb25nIGFzIGVwaGVtZXJhbCBrZXkgZXhjaGFuZ2UgYXJlIHVzZWQiDQoNCiAgQXMgdGhlIGVw aGVtZXJhbCBwYXJ0IGlzIG5vdCBwYXJ0IG9mIHRoZSBjaXBoZXIgc3VpdGVzIGFueW1vcmUuDQoN Ci0gU2VjdGlvbiA0LjEuMyAiSXQgZG9lcyBub3QgcHJvdmlkZSBkb3duZ3JhZGUgcHJvdGVjdGlv biB3aGVuIHN0YXRpYyBSU0ENCiAgaXMgdXNlZC4iDQogIEkgZG9uJ3Qga25vdyB0aGUgZGV0YWls cyBvZiBTZXJ2ZXJLZXlFeGNoYW5nZSwgYnV0IGl0IHRoaXMgbm90IHRydWUgZm9yDQogIG5vbi1E SEUgUFNLIGFzIHdlbGw/DQoNCi0gU2VjdGlvbiA0LjIuNA0KICBJIGRvIG5vdCByZWFsbHkgdW5k ZXJzdGFuZCB3aHkgdGhlIHByaXZhdGVfdXNlIGRpdmlkZWQgYW5kIHJlc3RpY3RlZD8NCiAgSS5l LiBmZmRoZV9wcml2YXRlX3VzZSBhbmQgZWNkaGVfcHJpdmF0ZV91c2UuIEkgdGhpbmsgaXQgd291 bGQgYmUNCiAgcHJlZmVyYWJsZSB0byBqdXN0IGhhdmUgInByaXZhdGVfdXNlIiB3aXRob3V0IHNw ZWNpZnlpbmcgdGhlIGV4YWN0IHVzZS4NCiAgV2hlcmUgZG8gSSBlLmcuIHB1dCBteSBwcml2YXRl IHVzRSBTSURILCBhbmQgTGF0dGljZS1iYXNlZCBrZXkgZXhjaGFuZ2UNCiAgaW5mb3JtYXRpb24u IEZlZWxzIGxpa2UgdGhpcyBpcyB0aGUgbmF0dXJhbCBwbGFjZSwgb3IgaXMgdGhlIGludGVudGlv bg0KICB0aGF0IGEgbmV3IGV4dGVuc2lvbiBpcyByZXF1aXJlZCBmb3IgUFFDPw0KDQotIFNlY3Rp b24gNC4yLjgNCiAgT0xEICJ0aGUgc2VydmVyIE1VU1QgaGF2ZSBhY2NlcHRlZCBhIFBTSyBjaXBo ZXIgc3VpdGUiDQogIE5FVyAidGhlIHNlcnZlciBNVVNUIGhhdmUgYWNjZXB0ZWQgYSBQU0sga2V5 IGV4Y2hhbmdlIG1vZGUiDQoNCi0gU2VjdGlvbiA1LjUgInVwIHRvIDJeMjQuNSBmdWxsLXNpemUg cmVjb3JkcyINCg0KICBJdCBpcyBub3Qgd2VsbC1kZWZpbmVkIG9uIGhvdyB0byBkbyB3aXRoIG5v bi1mdWxsLXNpemUgcmVjb3Jkcy4gSSBzdWdnZXN0DQoNCiAgT0xEICJ1cCB0byAyXjI0LjUgZnVs bC1zaXplIHJlY29yZHMiDQogIE5FVyDigJx1cCB0byAyXjI0LjUgcmVjb3JkcyINCg0KLSBTZWN0 aW9uIDUuNQ0KICBMaW1pdHMgYXJlIG5lZWRlZCBhbHNvIGZvciBBRVMtQ0NNLiBJdCBzaG91bGQg YWxzbyBiZSBzdGF0ZWQgdGhhdCBuZXcNCiAgc3BlY2lmaWNhdGlvbnMgZGVmaW5pbmcgbmV3IFRM UyBjaXBoZXJzIFNIQUxMIHByb3ZpZGUgbG1pdHMgb24gdGhlIG51bWJlcg0KICBvZiByZWNvcmRz IHRoYXQgY2FuIGJlIHByb3RlY3RlZCB3aXRoIGEgZ2l2ZW4ga2V5Lg0KDQogIEFzIGZhciBhcyBJ IHVuZGVyc3RhbmQgdGhlIGNvbmZpZGVudGlhbGl0eSBsaW1pdHMgZm9yIEFFUy1DQ00gKGFuZCBD VFINCiAgYW5kIENCQykgd291bGQgYmUgdGhlIHNhbWUgYXMgZm9yIEFFUy1HQ00uIEkgc3VnZ2Vz dA0KICANCiAgT0xEICJGb3IgQUVTLUdDTSwgdXAgdG8gMl4yNC41IGZ1bGwtc2l6ZSByZWNvcmRz Ig0KICBORVcgIkZvciBBRVMtR0NNIGFuZCBBRVMtQ0NNLCB1cCB0byAyXjI0LjUgcmVjb3JkcyIN CiANCiAgVGhlc2UgbGltaXRzIGFyZSBxdWl0ZSBoYXJkLCBidXQgSSB0aGluayB0aGF0IGlzIGZp bmUgYXMgaXQgc2hvdWxkIG5vdCBiZQ0KICBhIHByb2JsZW0gdG8gcmVrZXkgZnJlcXVlbnRseS4N CiANCi0gU2VjdGlvbiA1LjUgImZvciBBdXRoZW50aWNhdGVkIEVuY3J5cHRpb24gKEFFKSBzZWN1 cml0eS4iDQogIEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIHN0YXRlIHRoYXQgdGhpcyBpcyBjb25m aWRlbnRpYWxpdHkgKGluIGNvbnN0cmFzdA0KICB0byBpbnRlZ3JpdHkgb3Iga2V5IHJlY292ZXJ5 KS4gU3VnZ2VzdGlvbg0KICANCiAgT0xEICJmb3IgQXV0aGVudGljYXRlZCBFbmNyeXB0aW9uIChB RSkgc2VjdXJpdHkuIg0KICBORVcgImZvciBhbiBjb25maWRlbnRpYWxpdHkgYXR0YWNrIg0KDQot IFNlY3Rpb24gOA0KICBUaGUgc2VudGVuY2VzICJJbiB0aGUgYWJzZW5jZSBvZiBhbiBhcHBsaWNh dGlvbiBwcm9maWxlIHN0YW5kYXJkDQogIHNwZWNpZnlpbmcgb3RoZXJ3aXNlIiBvbmx5IGFwcGx5 IHRvIHNvbWUgcGFydHMgb2YgU2VjdGlvbiA4LiBFLmcuIGl0DQogIGFwcGxpZXMgdG8gY2lwaGVy IHN1aXRlcyBidXQgbm90IHRvIHRoZSBEaWZmaWUtSGVsbG1hbiBncm91cHMuIEZlZWxzIGxpa2UN CiAgdGhpcyBzaG91bGQgYXBwbHkgdG8gdGhlIHdob2xlIHNlY3Rpb24uIEkgc3VnZ2VzdCByZW1v dmluZyB0aGUgY3VycmVudA0KICBvY2N1cnJlbmNlcyBvZiAiIkluIHRoZSBhYnNlbmNlIG9mIGFu IGFwcGxpY2F0aW9uIHByb2ZpbGUgc3RhbmRhcmQNCiAgc3BlY2lmeWluZyBvdGhlcndpc2UiIGFu ZCBhZGQgKGF0IHRoZSBzdGFydCBvZiBTZWN0aW9uIDguKQ0KDQogICJJbiB0aGUgYWJzZW5jZSBv ZiBhbiBhcHBsaWNhdGlvbiBwcm9maWxlIHN0YW5kYXJkIHNwZWNpZnlpbmcgb3RoZXJ3aXNlLA0K ICB0aGUgZm9sbG93aW5nIHJlcXVpcmVtZW50cyBhcHBseSIuDQoNCi0gU2VjdGlvbiA4LjEgYW5k IDguMg0KICBUaGUgaGVhZGluZyBzYXlzICJNVEkiIGJ1dCB0aGUgdGV4dCBhbHNvIGNvbnRhaW5z IG5vbi1tYW5kYXRvcnkgdGhpbmdzDQogIChTSE9VTEQpDQoNCiAgSSBzdWdnZXN0IGNoYW5naW5n ICJNVEkiIHRvICJSZXF1aXJlbWVudHMiDQoNCi0gU2VjdGlvbiA4LjENCiAgVGhlIHRpdGxlIGlz ICJjaXBoZXIgc3VpdGVzIiwgYnV0IHRoZSBzY29wZSBpcyBicm9hZGVyIChzaWduYXR1cmVzIGFu ZA0KICBrZXkgZXhjaGFuZ2UpLiBJIHN1Z2dlc3QgY2hhbmdpbmcgdGhlIGhlYWRpbmcgdG8NCiAg DQogICJSZXF1aXJlbWVudHMgZm9yIGNpcGhlciBzdWl0ZXMsIHNpZ25hdHVyZXMsIGFuZCBncm91 cHMiDQoNCi0gU2VjdGlvbiA4LjIgVGhpcyBzZWN0aW9uIHNlZW1zIHRvIGZvcmdldCBwc2tfa2V5 X2V4Y2hhbmdlX21vZGVzLiBJZg0KICBwcmVfc2hhcmVkX2tleSBpcyBtYW5kYXRvcnkgdGhlbiBw c2tfa2V5X2V4Y2hhbmdlX21vZGVzIHNob3VsZCBiZSB0by4NCg0KLSBTZWN0aW9uIDk6IFNob3Vs ZCBtZW50aW9uIHRoYXQgYW4gYXR0YWNrZXIgYXQgYW55IHBvaW50IGNhbiB0ZXJtaW5hdGUgdGhl DQogIHNlc3Npb24gYnkgc2VuZGluZyBhIHNpbmdsZSBtYWxmb3JtZWQgcGFja2V0LiBUaGlzIHRl cm1pbmF0aW9uIGZlYXR1cmUgaXMNCiAgYm90aCBwb3NpdGl2ZSBhbmQgbmVnYXRpdmUuDQoNCi0g U2VjdGlvbiAxMS4yOiBbUkZDNDI3OV0gaXMgYW4gaW5mb3JtYXRpdmUgcmVmZXJlbmNlIGJ1dCBu ZXZlciByZWZlcnJlZA0KICB0by4NCg0KLSBTZWN0aW9uIEEuNCAiVExTIDEuMiBhbmQgbG93ZXIg Y2lwaGVyIHN1aXRlcyBjYW5ub3QgYmUgdXNlZCB3aXRoDQogIFRMUyAxLjMuIiBJIGNhbm5vdCBm aW5kIGFueSB0ZXh0IGluIHRoZSBkcmFmdCBzdGF0aW5uIHRoYXQgeW91IGNhbg0KICBuZWdvdGlh dGUgVExTIDEuMiBjaXBoZXIgc3VpdGVzIGluIFRMUyAxLjMsIEkgdGhpbmsgdGhpcyBzaG91bGQg YmUNCiAgc3RhdGVkLg0KICANCiAgT0xEOiAiVExTIDEuMiBhbmQgbG93ZXIgY2lwaGVyIHN1aXRl cyBjYW5ub3QgYmUgdXNlZCB3aXRoIFRMUyAxLjMuIg0KICBORVc6ICJUTFMgMS4yIGFuZCBsb3dl ciBjaXBoZXIgc3VpdGVzIGNhbm5vdCBiZSB1c2VkIHdpdGggVExTIDEuMywgYnV0DQogICAgICAg Y2FuIGJlIG5lZ290aWF0ZWQgaW4gYSBUTFMgMS4zIENsaWVudCBIZWxsby4iDQoNCi0gU2VjdGlv biBELjINCiAgT0xEICJ3ZWFrZXIgdGhhbiAyMDQ4LWJpdCBSU0Egb3IgMjI0LWJpdCBFQ0RTQSBh cmUgbm90IGFwcHJvcHJpYXRlIg0KICBORVcgIndlYWtlciB0aGFuIDIwNDgtYml0IFJTQSwgMjI0 LWJpdCBFQ0RTQSwgb3IgMTI4LWJpdCBQU0sgYXJlIG5vdA0KICAgICAgYXBwcm9wcmlhdGUiDQoN Ci0gU2VjdGlvbiBELjIgIlRoZSByZWFkZXIgc2hvdWxkIHJlZmVyIHRvIHRoZSBmb2xsb3dpbmcg cmVmZXJlbmNlcyBmb3INCiAgYW5hbHlzaXMgb2YgdGhlIFRMUyByZWNvcmQgbGF5ZXIuIg0KICAg DQogIE5vIHJlZmVyZW5jZXMgZ2l2ZW4uDQoNCiANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KSk9ITiBNQVRUU1NPTg0K TVNjIEVuZ2luZWVyaW5nIFBoeXNpY3MsIE1TYyBCdXNpbmVzcyBBZG1pbmlzdHJhdGlvbiBhbmQg RWNvbm9taWNzDQpFcmljc3NvbiBJRVRGIFNlY3VyaXR5IENvb3JkaW5hdG9yDQpTZW5pb3IgUmVz ZWFyY2hlciwgU2VjdXJpdHkNCg0K From nobody Sun Nov 20 06:09:45 2016 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 9E8631294DF for ; Sun, 20 Nov 2016 06:09:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yWRdAL8VP18I for ; Sun, 20 Nov 2016 06:09:42 -0800 (PST) Received: from mail-pg0-x229.google.com (mail-pg0-x229.google.com [IPv6:2607:f8b0:400e:c05::229]) (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 29C581294EA for ; Sun, 20 Nov 2016 06:09:42 -0800 (PST) Received: by mail-pg0-x229.google.com with SMTP id f188so120528825pgc.3 for ; Sun, 20 Nov 2016 06:09:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=5fdnOQatqfrExa1245or7IQzt+ZnNSp+9nI8ulSvVEY=; b=ZlkYTe09hHegBDG5orhhrYSC1+OOmwb0wrg9fTZuT0TCqk3gErN5bgUG8RIfOnuDDt yZxoZNJe4U0iH1RZHEvXtrXImhZ3ziy7kvYTdmZoudtL5Bvp/9qm3Xl5+XGD7xxkKtTG 7KaV1H3A7NQi7Jc/If7hassvOJC8uC42+JgfEnsodcQlfYVC6L6dffll2PNUurmgrcOI XDvDXI/jkeb7upCgqLmNJmPexVivCHf0Q5kTZAgrFsdo96HmMy9PABLSPC7V3jVVdDhZ +CaGvIHh8HgPMyRduiVA7Yrt81FttfV/79zawIdtqRZfFq96XZg5uDFdVkfhbesX38C2 F8sQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=5fdnOQatqfrExa1245or7IQzt+ZnNSp+9nI8ulSvVEY=; b=b8U5Dshanqm9D3lsqZD40JGXwOduzniFD8A9ConPhGPMoFe5oyBMwUqu6kOHX181x3 wUv3IxHB5uKisVOKsZ5m+nz9hqB5qVJ5J1IGQNo9akbDyh10RWvQUUEYrw8R8pYCgwKh SND3qRUnXnbsHCzk2hemgzPAdGf1mruQ2UqxUqHj1fBMnvHanCJgVbMZ5zLA4q+buv45 w09BpQHqk+UOGqpF9/lfoYGt+Vw1Kwju+V9koHTtX4tYwKxJqmiH9cthaoZG28TXSazL Si5OdU9swYD2UD6LcAC+TcV/ha9mmGVf84VKyC50EmkdpoiTKT+TzkDOnZ97HhiD8Qhp 57+g== X-Gm-Message-State: AKaTC02scE07TX6YTnUI9Dumuw0zF7jffF07TlyQDcTu8hAlT6k33zFp+f//84dwiWWNaA== X-Received: by 10.99.48.68 with SMTP id w65mr21063593pgw.68.1479650981480; Sun, 20 Nov 2016 06:09:41 -0800 (PST) Received: from [192.168.0.53] ([116.84.50.12]) by smtp.gmail.com with ESMTPSA id v1sm12732921pgv.33.2016.11.20.06.09.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2016 06:09:40 -0800 (PST) To: "Salz, Rich" , Sean Turner , "" References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <7462904085cc4a94914298af81157031@usma1ex-dag1mb1.msg.corp.akamai.com> From: Yaron Sheffer Message-ID: <7de8f9da-8ab1-cfc2-00ad-9c91c7694174@gmail.com> Date: Sun, 20 Nov 2016 23:09:37 +0900 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <7462904085cc4a94914298af81157031@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 20 Nov 2016 14:09:43 -0000 Hi Rich, I am confused by your response. For those who missed CURDLE, could you please briefly explain why we don't need signature context in non-TLS areas. And even if this is the case, the current thread is about TLS! So why are we now saying that contexts are not needed even for TLS? Thanks, Yaron On 20/11/16 13:21, Salz, Rich wrote: > In CURDLE this week, we had consensus (to be confirmed on the list, of course) that > Signature contexts were created in the TLS arena, we all thought we needed them in other areas, and we don't, therefore all CURDLE documents for those other areas will specify a zero-length context. > > FWIW. > > I agree with Yoav's message, for the reasons he states. > > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz > > >> -----Original Message----- >> From: Sean Turner [mailto:sean@sn3rd.com] >> Sent: Friday, November 18, 2016 6:56 PM >> To: >> Subject: [TLS] WGLC for draft-ietf-tls-rfc4492bis >> >> All, >> >> This is a working group last call for the “4492bis to Standards Track" draft >> available @ http://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/. Please >> review the document and send your comments to the list by 9 December >> 2016. >> >> Note that we are particularly interesting in the issue Yoav raises in the >> following message: >> https://mailarchive.ietf.org/arch/msg/tls/8Ec7jQqLr_3FrvQfuclllfozKZk >> >> Thanks, >> J&S >> _______________________________________________ >> 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 > From nobody Sun Nov 20 07:33:53 2016 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 B37EF1295A3 for ; Sun, 20 Nov 2016 07:33:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 zOsmmswIFxqh for ; Sun, 20 Nov 2016 07:33:50 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id B01D31293DC for ; Sun, 20 Nov 2016 07:33:50 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 3020C423710; Sun, 20 Nov 2016 15:33:50 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 19AA342370E; Sun, 20 Nov 2016 15:33:50 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479656030; bh=uH8YjSiB52G3XXHVgKlNG252gUqNhpesxqwBP+GLyas=; l=708; h=From:To:Date:References:In-Reply-To:From; b=ZGOXEMEWsD9VcuEqXmL38ceJgRfY7OYhojjhxx6tpyI1G0kBJltafqHowy107ebd5 jGVJ0vqF6X7Gl1a9Z+XA72e68yyH/iYMr+DUgoKNo547cM4GB5jHieQxya8VdrWCxd Vl4N6MVpNfoov7gzUT16ApPe49x4b2hP3CovSf/U= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 162BB1FC86; Sun, 20 Nov 2016 15:33:50 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Sun, 20 Nov 2016 10:33:49 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Sun, 20 Nov 2016 10:33:49 -0500 From: "Salz, Rich" To: Yaron Sheffer , Sean Turner , "" Thread-Topic: [TLS] WGLC for draft-ietf-tls-rfc4492bis Thread-Index: AQHSQh6Z9X1Hg0mzJ0aKXLkuEjb/46DhRi7QgAD42oD//8NacA== Date: Sun, 20 Nov 2016 15:33:49 +0000 Message-ID: <8394bafcd99344838d878b5e8cf5b524@usma1ex-dag1mb1.msg.corp.akamai.com> References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <7462904085cc4a94914298af81157031@usma1ex-dag1mb1.msg.corp.akamai.com> <7de8f9da-8ab1-cfc2-00ad-9c91c7694174@gmail.com> In-Reply-To: <7de8f9da-8ab1-cfc2-00ad-9c91c7694174@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.33.78] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 20 Nov 2016 15:33:52 -0000 PiBGb3IgdGhvc2Ugd2hvIG1pc3NlZCBDVVJETEUsIGNvdWxkIHlvdSBwbGVhc2UgYnJpZWZseSBl eHBsYWluIHdoeSB3ZSBkb24ndA0KPiBuZWVkIHNpZ25hdHVyZSBjb250ZXh0IGluIG5vbi1UTFMg YXJlYXMuDQoNClRoZSBvbmUgcGxhY2Ugd2Ugd2VyZSBjb25jZXJuZWQgYWJvdXQgYXR0YWNrcyB3 YXMgaW4gcHJlLWhhc2ggc2lnbmF0dXJlcywgYW5kIHdlIG1hZGUgdGhvc2UgYSBNVVNUIE5PVC4g IEFuZCB5ZXMsIHlvdXInZSByaWdodCwgaXQncyBub3QgcmVsZXZhbnQgdG8gVExTLg0KDQo+IFNv IHdoeSBhcmUgd2Ugbm93IHNheWluZyB0aGF0IGNvbnRleHRzIGFyZSBub3QgbmVlZGVkIGV2ZW4g Zm9yIFRMUz8NCg0KSSB0aGluayBiZWNhdXNlIHRoZSBrZXkgc2NoZWR1bGUgY2hhbmdlZC4NCg0K LS0gIA0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRlY2hub2xvZ2llcw0KTWVtYmVyLCBPcGVu U1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVyLmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoN Cg0K From nobody Sun Nov 20 11:17:40 2016 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 BFB931297AC for ; Sun, 20 Nov 2016 11:17:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=filippo.io header.b=HJAwKARf; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=IwVCPUlL 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 tVoKoCHSA8eJ for ; Sun, 20 Nov 2016 11:17:38 -0800 (PST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94D52129481 for ; Sun, 20 Nov 2016 11:17:38 -0800 (PST) Received: from compute6.internal (compute6.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id E5ADA2068F for ; Sun, 20 Nov 2016 14:17:37 -0500 (EST) Received: from web1 ([10.202.2.211]) by compute6.internal (MEProxy); Sun, 20 Nov 2016 14:17:37 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=filippo.io; h= content-transfer-encoding:content-type:date:from:message-id :mime-version:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s= mesmtp; bh=WPcYnTX+4tJrL7kY7II768TZs8U=; b=HJAwKARfT7r8qwr0IAcok Gt6N5saij0gSKf2/xtE5Pcqf+tlDOIADekMYdECA0P/LwV0IlC0xu+pxs6lWxbw4 rAcisYyl+J8cynJ5KKl1M5IN5JwAXzlpRfRxrHIvCfJ8dsu9+VuabkvPDy+Bop76 P0YBycGlgXPPEy8GHQrTjw= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:message-id:mime-version:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=smtpout; bh=WPcYnTX+4tJrL7kY7II768TZs 8U=; b=IwVCPUlLYlJqE0KY54RJr7U6v8hYYF18eo9yerqloTyrXeCdgm4OOdBPI 6GoUT8kMkqHqpbsD8kCVnymhB8u3mYz9aBzvqdB8Tb4GATrgIUlc91yauDCEu1ip mt+2jW+lH0J80Mxlxbs8DixmJGa6ewuSNNmryYNSIDJiyY7P3A= X-ME-Sender: Received: by mailuser.nyi.internal (Postfix, from userid 99) id ADACFAA6AD; Sun, 20 Nov 2016 14:17:37 -0500 (EST) Message-Id: <1479669457.3015489.793828961.121B4C8F@webmail.messagingengine.com> From: Filippo Valsorda To: tls@ietf.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="utf-8" X-Mailer: MessagingEngine.com Webmail Interface - ajax-461bce03 Date: Sun, 20 Nov 2016 14:17:37 -0500 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 20 Nov 2016 19:17:40 -0000 I'm definitely for 1.3. I get where 4 is coming from, but 1.2 is not going anywhere soon, and we spent the last 10 years training people that the high-numbered one is bad, and that the 1.x ones are cool. I really don't want to have the following conversation, with the exact same people the proponents of 4 are trying to help: "You only support 1.2, you should support 4" "Oh, wasn't it that weird other way around where the high one was broken?" "Ah, no, 4 is the latest and greatest" "Oh, ok, then I should support only 4 and 3?" "Nono, 3 is terribly broken." "Oh, so only 4? Do all clients support it?" "Uh, you should keep 1.2" "Ah, so 1.2 is better than 3 but worse than 4?" "Yeah... I'm sorry" "4 is great, 3 is bad, 1.2 is good" is harder than "3 is bad, 1.2 is good" was, and harder than "3 is bad, 1.2 is good, 1.3 is great" would be. From nobody Sun Nov 20 16:56:31 2016 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 C83A012959B for ; Sun, 20 Nov 2016 16:56:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no 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 KSUA2MxYI6j9 for ; Sun, 20 Nov 2016 16:56:28 -0800 (PST) Received: from calvin.win.tue.nl (calvin.win.tue.nl [131.155.70.11]) by ietfa.amsl.com (Postfix) with SMTP id B06C7129594 for ; Sun, 20 Nov 2016 16:56:27 -0800 (PST) Received: (qmail 3824 invoked by uid 1017); 21 Nov 2016 00:56:25 -0000 Received: from unknown (unknown) by unknown with QMTP; 21 Nov 2016 00:56:25 -0000 Received: (qmail 1446 invoked by uid 1000); 21 Nov 2016 00:56:12 -0000 Date: 21 Nov 2016 00:56:12 -0000 Message-ID: <20161121005612.1445.qmail@cr.yp.to> Mail-Followup-To: tls@ietf.org From: "D. J. Bernstein" To: tls@ietf.org In-Reply-To: Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 00:56:30 -0000 The messages on the list seem to be perfectly split between "TLS 1.3" and "TLS 4". I suspect that the "TLS 2017" idea will break this impasse: * it shares the fundamental advantage that led to the "TLS 4" idea; * it has the additional advantage of making the age obvious; * it eliminates the "4 sounds too much like 3" complaint; and * it eliminates the "where are TLS 2 and TLS 3?" complaint. Perhaps it's worth starting a poll specifically between "TLS 1.3" and "TLS 2017"? Or at least asking whether the new "TLS 2017" option would swing some previous opinions? Of course people who prioritize retaining the existing "TLS 1.3" mindshare will be just as unhappy with "TLS 2017" as with "TLS 4", but they'll get over it within a few years. :-) ---Dan From nobody Sun Nov 20 17:16:51 2016 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 C72C7129626 for ; Sun, 20 Nov 2016 17:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 1q9D6LyUWWQh for ; Sun, 20 Nov 2016 17:16:49 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 40F101293F0 for ; Sun, 20 Nov 2016 17:16:49 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id a10so201020624ywa.3 for ; Sun, 20 Nov 2016 17:16:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=leUfSNEOE0Cp94akWxpoqTX59FIaZSmONtphKfDg/aU=; b=S/XiMIitkIh/MFPETHW9vA8pcFd3rEirzhvZWu/bUm4rI4m1NUO9v4mITQx4h8IDJE KxrG5K37O/oBu0AP+ub81q0kgJitbK41KJpfeKSwhCOf45AZMjLAh5YF5BVa/E4bvBEi v6yZx/6H/Unz21MDQtyJjI5eVyvb3djfA1yvR3voO2CN9oHiDy1cVE6mx41bP3lgcSea zxKv91qN8gF8L5BiEjseSww3LsYDbLZd200GYV5PTUJkcd1QiVQamhKjvOm9YVd//REV OH/nBNaLvWLEgnrMpPulGX43ptkDgo9cJET3zwgk4GgcaJiExFRfoxhN9w6327LQzIn8 Uc7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=leUfSNEOE0Cp94akWxpoqTX59FIaZSmONtphKfDg/aU=; b=bHKzNIvUnMlMwPUw0mErt8JTUn75/LdBgknj7/hef3fatjIyRnNSKGsZtizS/i2GNt bfe8irZg4OLmfRqgg3C+79mltoYpFNIkCE0qUqIu4O149HMYyzJEL04xipRbjXCdcN5L Iuo+3yWBtmiVYcXRTA8YVRdH1TdxkCzNRJ29KZyEmPhIyxsFIBavSFlsl86u+IhTosZ4 QUsQljSKZRW3lj5RZSqeJGrMN5pjGMZxFKlSZy8tmTJWJTccW1AYzC6X1KbAuuqPb0eh D+JzYPY7sjgiQhhud0/iVJik/KjMncAGl5fXHg0BpGB/6VTpv9nOr6SfCmJTqwjNJ3YZ Qcxw== X-Gm-Message-State: AKaTC01Og1vVwkc3jamsZNtb8YAjV00nUhlspLS75G6qYblaV1yjzEElQbXzurj5lCBmGM5+T6NHsZ34vCvJcg== X-Received: by 10.129.121.1 with SMTP id u1mr10800895ywc.146.1479691008497; Sun, 20 Nov 2016 17:16:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sun, 20 Nov 2016 17:16:07 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 20 Nov 2016 17:16:07 -0800 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=94eb2c0a8f82f08b450541c568dd Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 01:16:51 -0000 --94eb2c0a8f82f08b450541c568dd Content-Type: text/plain; charset=UTF-8 I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we're going to rev the major version number we should abandon the minor one). TLS 2017 strikes me as quite bad; we're certainly not planning to do a TLS 2018. I am strongly opposed to TLS 2017. -Ekr On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. > > Thanks, > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0a8f82f08b450541c568dd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we'= ;re going to rev the major version number we should abandon the minor one).=
TLS 2017 strikes me as quite bad; we're certainly not pl= anning to do a TLS 2018. I am strongly opposed to TLS 2017.

<= /div>
-Ekr


On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner <sean@sn3rd= .com> wrote:
At IETF 97, the chairs lead a discussion to resolve whether the WG sho= uld rebrand TLS1.3 to something else.=C2=A0 Slides can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pd= f.

The consensus in the room was to leave it as is, i.e., TLS1.3, and to not r= ebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this decisi= on on the list so please let the list know your top choice between:

- Leave it TLS 1.3
- Rebrand TLS 2.0
- Rebrand TLS 2
- Rebrand TLS 4

by 2 December 2016.

Thanks,
J&S
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c0a8f82f08b450541c568dd-- From nobody Sun Nov 20 17:42:41 2016 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 5974C129454 for ; Sun, 20 Nov 2016 17:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.267 X-Spam-Level: X-Spam-Status: No, score=-3.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=hotmail.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 hoCGMrMVP_XI for ; Sun, 20 Nov 2016 17:42:39 -0800 (PST) Received: from SNT004-OMC4S14.hotmail.com (snt004-omc4s14.hotmail.com [65.55.90.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F451126BF7 for ; Sun, 20 Nov 2016 17:42:39 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com ([65.55.90.199]) by SNT004-OMC4S14.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 20 Nov 2016 17:42:39 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hotmail.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B9Z6GR52JAvOsbVMvhqaGbJKrI/B+dzEwA1ICBNM3yE=; b=Zgd/BOmBS0ewGMR+N3O2eGwl1iBipJ2SYCkG6HK0z1Q4sX6y4hNCVgBaYJTjbFKO1vJ5japENlHdDn3qZFXfPlQikjs4doP1pB5OwBealHEMhTPvOonnGQ2ZYzUY5I/mBOs73HSLuN8LebF5GnWWup1WxTLwYr5HL2JI1u+Ukczirb5PL7Ef/QnNtp1ujuYmKb0dUKLC3OfIrBWmgJvpfahV9qt/FPAg5rGaYVoRdUe2fJEJg89UkcKQ7/i355s62ZX5i5G4+uVT14tSQA1qUT9+LlBpkQ6qJWJXB2hkWT+HmJiJxDUILOS52+cMdgWwD8QCHsuM1c8qOakCQ09+aw== Received: from BL2NAM02FT039.eop-nam02.prod.protection.outlook.com (10.152.76.53) by BL2NAM02HT039.eop-nam02.prod.protection.outlook.com (10.152.76.226) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.721.5; Mon, 21 Nov 2016 01:42:37 +0000 Received: from BY2PR18MB0342.namprd18.prod.outlook.com (10.152.76.51) by BL2NAM02FT039.mail.protection.outlook.com (10.152.77.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.4 via Frontend Transport; Mon, 21 Nov 2016 01:42:37 +0000 Received: from BY2PR18MB0342.namprd18.prod.outlook.com ([10.163.193.12]) by BY2PR18MB0342.namprd18.prod.outlook.com ([10.163.193.12]) with mapi id 15.01.0721.024; Mon, 21 Nov 2016 01:42:37 +0000 From: Yuhong Bao To: Joseph Salowey , "tls@ietf.org" Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 Thread-Index: AQHSL/2/Y48c/0f1ekKL0nwqIu5Fn6Di0QFC Date: Mon, 21 Nov 2016 01:42:37 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: salowey.net; dkim=none (message not signed) header.d=none;salowey.net; dmarc=none action=none header.from=hotmail.com; x-incomingtopheadermarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:7445; Count:38 x-tmn: [KIxUOtMf2YDLNLgHvw9Yt0NMZPUFveIgGrDz2WIFob0=] x-incomingheadercount: 38 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; BL2NAM02HT039; 5:aqRxoDeYa50YTVeaS+8uIARGb0g84Er5RDM9rz3cOrV/Kh4z8gXKAzm/d6cNSV9554elyiKrT/0QVmPXGddC4eEXxl8uw6b6Df7JyBK8vXnwVt1UIjC17j1CNw4TtQTNYaulKbQqYy9njZBEvidBEQ==; 24:naTRvqtnSzW6vpiAkUN412m9eZjDcSxRa90ycc9iJfJmJKPuxuVSS+BZQ9EUvzGl666uyqA5LpZdm+++EPj4MZwtE/woIDIlM/EtjJ6dtWU=; 7:S8Arenc5yF7xrhrOkzfXpIOk+rOxdJzozFPScR+InO6tsPNryp/TLoiUaA+RWBSqM3RCkoD6J5D57trNQXPvrML0P2Xft+z9ly7Bm9jZSBYJDVPhYwAhk8R+6Gg6yVUHyxa+U6H43TszCjWFFJeidv8hwR1WtCLZiT5+BMqI9tLIKfDycrpc1oEpEcjCH2ym/pAGSiK1TZWsHmZXHZ62RBrctBbT52UqcNxAiPER+ECFzI0IFtMO3s+Fs6LuarbatMzr9jgtMOU9cPRhO4JKU+JZCcEbFXguh+U3AhvfOR0hpNTRRI9FkrnfFQymbL4OWSX0gryIktY8wkEn9a0QS1HAjv1tUyrdGDOVkVZFgY0= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2NAM02HT039; H:BY2PR18MB0342.namprd18.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: 8c86ef1a-2d3e-48b3-4b5c-08d411afac5f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(1603103113)(1603101340)(1601125047); SRVR:BL2NAM02HT039; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:BL2NAM02HT039; BCL:0; PCL:0; RULEID:; SRVR:BL2NAM02HT039; x-forefront-prvs: 01334458E5 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: hotmail.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2016 01:42:37.4457 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL2NAM02HT039 X-OriginalArrivalTime: 21 Nov 2016 01:42:39.0246 (UTC) FILETIME=[8AF35AE0:01D24398] Archived-At: Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 01:42:41 -0000 I can't help but notice the text: "Versions of TLS before 1.3 supported compression with the list of supporte= d compression methods being sent in this field. For every TLS 1.3 ClientHel= lo, this vector MUST contain exactly one byte set to zero, which correspon= ds to the =93null=94 compression method in prior versions of TLS. If a TLS = 1.3 ClientHello is received with any other value in this field, the server = MUST abort the handshake with an =93illegal_parameter=94 alert. Note that = TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which contain o= ther compression methods and MUST follow the procedures for the appropriate= prior version of TLS." IMO, the compression methods section of ClientHello should be ignored as me= ntioned by Martin Rex. It may be too late for that, but RC4 IMO should be a SHOULD NOT not a MUST = NOT. One reason for that is that it is not broken the way that say 56-bit encryp= tion is. From: TLS on behalf of Joseph Salowey Sent: Wednesday, October 26, 2016 7:56 PM To: tls@ietf.org Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 =A0=20 This is a working group last call announcement for=A0draft-ietf-tls-tls13-1= 8, to run through=A0November 20. If possible, we=A0would like to receive c= omments on the list by=A0November 13=A0so they can=A0be discussed at the m= eeting in Seoul. We hope to address any=A0substantive issues raised during = that process shortly thereafter. In order to allow for cryptographic review, we will delay submission=A0of t= he draft to the IESG until the end of January 2017; there=A0will be an oppo= rtunity to address any issues discovered by the=A0cryptographic community = prior to submission to the IESG. Cheers, Joe = From nobody Sun Nov 20 17:52:08 2016 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 0E2D4129454 for ; Sun, 20 Nov 2016 17:52:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pobox.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 rrLNI0q38QFO for ; Sun, 20 Nov 2016 17:52:04 -0800 (PST) Received: from sasl.smtp.pobox.com (pb-smtp2.pobox.com [64.147.108.71]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7A0F1293E1 for ; Sun, 20 Nov 2016 17:52:04 -0800 (PST) Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id B784A51FC7 for ; Sun, 20 Nov 2016 20:52:03 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sasl; bh=gQThHgZKqnxPHwVzBNQnNyv2cI8=; b=PE21Qb C0D1hoBXJQpWf10VTbZVc2oskj/3eITAH+sG3hKEtCTPIocEJSa4Ykj6vXPUxM99 ErapXnxUko2DmhBsUwfM/usFtJXMzRYDI+0gmuMxRZxtejJcDe/WGR/6qGH9WiAV /5rnMTiNPPkjCD8wMonkfr67twAueseCuHjcg= Received: from pb-smtp2.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp2.pobox.com (Postfix) with ESMTP id AEC7951FC6 for ; Sun, 20 Nov 2016 20:52:03 -0500 (EST) Received: from mail-qk0-f173.google.com (unknown [209.85.220.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pb-smtp2.pobox.com (Postfix) with ESMTPSA id 43A4051FC2 for ; Sun, 20 Nov 2016 20:52:03 -0500 (EST) Received: by mail-qk0-f173.google.com with SMTP id n204so333381293qke.2 for ; Sun, 20 Nov 2016 17:52:03 -0800 (PST) X-Gm-Message-State: AKaTC01bZdGooCsFZ/xVdM1OqKj2xbMMouPhIr4vkYUYsQ2cKOx4r3vA2bunmHqW711aw8VsGtrRo0j6VTYjhA== X-Received: by 10.55.207.78 with SMTP id e75mr15266034qkj.36.1479693122613; Sun, 20 Nov 2016 17:52:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.200.44.205 with HTTP; Sun, 20 Nov 2016 17:51:21 -0800 (PST) In-Reply-To: <1479669457.3015489.793828961.121B4C8F@webmail.messagingengine.com> References: <1479669457.3015489.793828961.121B4C8F@webmail.messagingengine.com> From: Eric Mill Date: Sun, 20 Nov 2016 20:51:21 -0500 X-Gmail-Original-Message-ID: Message-ID: To: Filippo Valsorda Content-Type: multipart/alternative; boundary=001a1145b7b8f347350541c5e6a0 X-Pobox-Relay-ID: 1968B062-AF8D-11E6-A51A-3AB77A1B28F4-82875391!pb-smtp2.pobox.com Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 01:52:07 -0000 --001a1145b7b8f347350541c5e6a0 Content-Type: text/plain; charset=UTF-8 On Sun, Nov 20, 2016 at 2:17 PM, Filippo Valsorda wrote: > I'm definitely for 1.3. > > I get where 4 is coming from, but 1.2 is not going anywhere soon, and we > spent the last 10 years training people that the high-numbered one is > bad, and that the 1.x ones are cool. > > I really don't want to have the following conversation, with the exact > same people the proponents of 4 are trying to help: > > "You only support 1.2, you should support 4" > "Oh, wasn't it that weird other way around where the high one was > broken?" > "Ah, no, 4 is the latest and greatest" > "Oh, ok, then I should support only 4 and 3?" > "Nono, 3 is terribly broken." > "Oh, so only 4? Do all clients support it?" > "Uh, you should keep 1.2" > "Ah, so 1.2 is better than 3 but worse than 4?" > "Yeah... I'm sorry" > > "4 is great, 3 is bad, 1.2 is good" is harder than "3 is bad, 1.2 is > good" was, and harder than "3 is bad, 1.2 is good, 1.3 is great" would > be. > While this conversation might not be impossible, I think it's an unlikely hypothetical. A change to TLS 4 wouldn't be to address confusion for those who have already internalized the weird version history (which is mostly people like us on-list), but for people who only think about TLS/SSL when they're forced to think about it, once every year or few. For those people, the real conversations I've had were based on superficial glances and hazy memories of the protocol history that are reconstituted every time the subject comes up. Naming it TLS 4 wouldn't fix it for everyone, but it would be all-upside for some -- as well as providing a helpful opportunity to drop the faux-minor version number and simplify the numbering overall in the long term. The near-term annoyance of renaming things by folks close to the WG, and the chance of some confusion around the edges, seem like small issues compared to a positive investment in bending the sanity curve of the next 20 years of lazy enterprise decisions. -- Eric > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- konklone.com | @konklone --001a1145b7b8f347350541c5e6a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 20, 2016 at 2:17 PM, Filippo Valsorda <= ;ml@filippo.io> wrote:
I'm definitely for 1.3.<= br>
I get where 4 is coming from, but 1.2 is not going anywhere soon, and we spent the last 10 years training people that the high-numbered one is
bad, and that the 1.x ones are cool.

I really don't want to have the following conversation, with the exact<= br> same people the proponents of 4 are trying to help:

"You only support 1.2, you should support 4"
"Oh, wasn't it that weird other way around where the high one was<= br> broken?"
"Ah, no, 4 is the latest and greatest"
"Oh, ok, then I should support only 4 and 3?"
"Nono, 3 is terribly broken."
"Oh, so only 4? Do all clients support it?"
"Uh, you should keep 1.2"
"Ah, so 1.2 is better than 3 but worse than 4?"
"Yeah... I'm sorry"

"4 is great, 3 is bad, 1.2 is good" is harder than "3 is bad= , 1.2 is
good" was, and harder than "3 is bad, 1.2 is good, 1.3 is great&q= uot; would
be.

While this conversation might not b= e impossible, I think it's an unlikely hypothetical. A change to TLS 4 = wouldn't be to address confusion for those who have already internalize= d the weird version history (which is mostly people like us on-list), but f= or people who only think about TLS/SSL when they're forced to think abo= ut it, once every year or few.

For those people, t= he real conversations I've had were based on superficial glances and ha= zy memories of the protocol history that are reconstituted every time the s= ubject comes up. Naming it TLS 4 wouldn't fix it for everyone, but it w= ould be all-upside for some -- as well as providing a helpful opportunity t= o drop the faux-minor version number and simplify the numbering overall in = the long term.

The near-term annoyance of renaming= things by folks close to the WG, and the chance of some confusion around t= he edges, seem like small issues compared to a positive investment in bendi= ng the sanity curve of the next 20 years of lazy enterprise decisions.

-- Eric
=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



--
=
--001a1145b7b8f347350541c5e6a0-- From nobody Sun Nov 20 18:55:52 2016 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 47EE112947E for ; Sun, 20 Nov 2016 18:55:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5] autolearn=ham autolearn_force=no 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 tXINQQnFQXJM for ; Sun, 20 Nov 2016 18:55:49 -0800 (PST) Received: from elasmtp-scoter.atl.sa.earthlink.net (elasmtp-scoter.atl.sa.earthlink.net [209.86.89.67]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC2D01293FE for ; Sun, 20 Nov 2016 18:55:49 -0800 (PST) Received: from [47.143.125.162] (helo=Williams-MacBook-Pro.local) by elasmtp-scoter.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1c8elZ-0002XP-6h; Sun, 20 Nov 2016 21:55:33 -0500 Date: Sun, 20 Nov 2016 18:55:28 -0800 From: Bill Frantz To: "D. J. Bernstein" X-Priority: 3 In-Reply-To: <20161121005612.1445.qmail@cr.yp.to> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79c541e900d525ac77c307051764655009350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.162 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 02:55:51 -0000 On 11/21/16 at 4:56 PM, djb@cr.yp.to (D. J. Bernstein) wrote: >The messages on the list seem to be perfectly split between "TLS 1.3" >and "TLS 4". I suspect that the "TLS 2017" idea will break this impasse: > >* it shares the fundamental advantage that led to the "TLS 4" idea; >* it has the additional advantage of making the age obvious; >* it eliminates the "4 sounds too much like 3" complaint; and >* it eliminates the "where are TLS 2 and TLS 3?" complaint. > >Perhaps it's worth starting a poll specifically between "TLS 1.3" and >"TLS 2017"? Or at least asking whether the new "TLS 2017" option would >swing some previous opinions? > >Of course people who prioritize retaining the existing "TLS 1.3" >mindshare will be just as unhappy with "TLS 2017" as with "TLS 4", but >they'll get over it within a few years. :-) The Ecmascript standards body, TC39 has moved to year =3D=3D=3D=20 version. It seems to work well for them. I don't think that using a year means that there will be a new=20 standard every year. In the unlikely event that there is a standard bug bad enough to=20 need a second standard in one year, decimal version(s) could be=20 used e.g 2017.1. It would be understandable and act as=20 punishment for us who screwed up. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Concurrency is hard. 12 out | Periwinkle (408)356-8506 | 10 programmers get it wrong. | 16345=20 Englewood Ave www.pwpconsult.com | - Jeff Frantz | Los Gatos,=20 CA 95032 From nobody Sun Nov 20 19:14:23 2016 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 20D6B129429 for ; Sun, 20 Nov 2016 19:14:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 ifNdM2QRku90 for ; Sun, 20 Nov 2016 19:14:20 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 2A730129401 for ; Sun, 20 Nov 2016 19:14:20 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id r204so202375711ywb.0 for ; Sun, 20 Nov 2016 19:14:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Rk/YgyPl4oXY3i5o9lY+U8P/dIZvViSkWlQHLXThBPE=; b=wYxdOFqm60QLGe1uiiLnoLkXpez4+1b1njQyP1sJFZKP8LNU9niTAnpmSn+/75dtyt tVwUU5E+vIHCe23YIRjeSvhVG8eR9JXX0X9yrhqpm9PIC94EcBimHunaamUpf+09b82s TaPrxxEKh8A+FZhAMqBFGj38XEcz7zhO/oX2ahpAj5ZzF9Tcs3d8/i3ccWI0Fuy6abOx 6g7fW/mQSl5uWAbAAXU5ePD//7SMig0aSlxP7CViFm5C5N9jA6KTlBtQetdUL7Nvzdu6 rlN/xGbzaaDbRIgr/9qyDjTprW6VQqZuc+eX2TMhxIZfbMJiVy7CFYogHWOzdjkjQJbU jVnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Rk/YgyPl4oXY3i5o9lY+U8P/dIZvViSkWlQHLXThBPE=; b=CRPd5Cbs5Seaos21hQVywzxHVt6pnecTkyXVxYXtXplPnZ5QRV+FS3irFuBcJsm6L9 V8PtZcZ+LAZmrB0XMdr/DHDfA8931hbBQHCzemE1LK28y5YtvEyHKEA4x3DZsoFpRJtG I9tn2gkrqV6Ig20hI4Q17O+bgt0smMMpaVEPfYLH4s3xlaJa5kGgPer935M2BUWSCrot MdKFDeMzmUz7N373QjxLQR3px7s620d4HQ8jlGvJf9lfpqSB9woirgA3Ff2wqtmuTxu5 6JWx9nTFkM4XCvMvlIr6XKXhrifTqsFRMFzrhTZvVDs2vxPKlBU/Bc9BxGWpZ4OJp4e7 w7Ug== X-Gm-Message-State: AKaTC03Pq0sJydDtdwpnVlWiUCJg5rVmwLclAzUtzO/MjT8/1QxBL2gH/n8hyq7JnlDNYlaCdOoFMduiReWpIQ== X-Received: by 10.129.53.194 with SMTP id c185mr11496255ywa.205.1479698059313; Sun, 20 Nov 2016 19:14:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sun, 20 Nov 2016 19:13:38 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Sun, 20 Nov 2016 19:13:38 -0800 Message-ID: To: Yuhong Bao Content-Type: multipart/alternative; boundary=001a1142147833932d0541c70d82 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 03:14:22 -0000 --001a1142147833932d0541c70d82 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sun, Nov 20, 2016 at 5:42 PM, Yuhong Bao wrote: > I can't help but notice the text: > "Versions of TLS before 1.3 supported compression with the list of > supported compression methods being sent in this field. For every TLS 1.3 > ClientHello, this vector MUST contain exactly one byte set to zero, whic= h > corresponds to the =E2=80=9Cnull=E2=80=9D compression method in prior ver= sions of TLS. If a > TLS 1.3 ClientHello is received with any other value in this field, the > server MUST abort the handshake with an =E2=80=9Cillegal_parameter=E2=80= =9D alert. Note > that TLS 1.3 servers might receive TLS 1.2 or prior ClientHellos which > contain other compression methods and MUST follow the procedures for the > appropriate prior version of TLS." > IMO, the compression methods section of ClientHello should be ignored as > mentioned by Martin Rex. I'm not seeing any good reason for this. We don't want anyone to offer compression and it's not like it's difficult for 1.3 implementations to not offer it. It may be too late for that, but RC4 IMO should be a SHOULD NOT not a MUST > NOT. > One reason for that is that it is not broken the way that say 56-bit > encryption is. > The IETF has already decided this issue: https://tools.ietf.org/rfcmarkup?doc=3D7465 -Ekr > From: TLS on behalf of Joseph Salowey < > joe@salowey.net> > Sent: Wednesday, October 26, 2016 7:56 PM > To: tls@ietf.org > Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 > > > This is a working group last call announcement > for draft-ietf-tls-tls13-18, to run through November 20. If possible, > we would like to receive comments on the list by November 13 so they > can be discussed at the meeting in Seoul. We hope to address > any substantive issues raised during that process shortly thereafter. > > > In order to allow for cryptographic review, we will delay submission of > the draft to the IESG until the end of January 2017; there will be an > opportunity to address any issues discovered by the cryptographic > community prior to submission to the IESG. > > > Cheers, > > > Joe > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1142147833932d0541c70d82 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sun, Nov 20, 2016 at 5:42 PM, Yuhong Bao <YuhongBao_386@hot= mail.com> wrote:
I can't help but notice the text:
"Versions of TLS before 1.3 supported compression with the list of sup= ported compression methods being sent in this field. For every TLS 1.3 Clie= ntHello,=C2=A0 this vector MUST contain exactly one byte set to zero, which= corresponds to the =E2=80=9Cnull=E2=80=9D compression method in prior vers= ions of TLS. If a TLS 1.3 ClientHello is received with any other value in t= his field, the server MUST abort the handshake with an =E2=80=9Cillegal_par= ameter=E2=80=9D=C2=A0 alert. Note that TLS 1.3 servers might receive TLS 1.= 2 or prior ClientHellos which contain other compression methods and MUST fo= llow the procedures for the appropriate prior version of TLS."
IMO, the compression methods section of ClientHello should be ignored as me= ntioned by Martin Rex.

I'm not seeing a= ny good reason for this. We don't want anyone to offer compression and = it's not
like it's difficult for 1.3 implementations to n= ot offer it.


It may be too late for that, but RC4 IMO should be a SHOULD NOT not a MUST = NOT.
One reason for that is that it is not broken the way that say 56-bit encryp= tion is.

The IETF has already decided t= his issue:

<= div>-Ekr



From: TLS <tls-bounces@ietf.org<= /a>> on behalf of Joseph Salowey <= joe@salowey.net>
Sent: Wednesday, October 26, 2016 7:56 PM
To: tls@ietf.org
Subject: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18
=C2=A0

This is a working group last call announcement for=C2=A0draft-ietf-tls-tls1= 3-18, to run through=C2=A0November=C2=A0 20. If possible, we=C2=A0would lik= e to receive comments on the list by=C2=A0November 13=C2=A0so=C2=A0 they ca= n=C2=A0be discussed at the meeting in Seoul. We hope to address any=C2=A0su= bstantive issues raised during that process shortly thereafter.


In order to allow for cryptographic review, we will delay submission=C2=A0o= f the draft to the IESG until the end of January 2017; there=C2=A0will be a= n opportunity to address=C2=A0 any issues discovered by the=C2=A0cryptograp= hic community prior to submission to the IESG.


Cheers,


Joe


___________= ____________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1142147833932d0541c70d82-- From nobody Sun Nov 20 19:27:43 2016 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 010341296AB for ; Sun, 20 Nov 2016 19:27:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuytHCByFnKH for ; Sun, 20 Nov 2016 19:27:39 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 7BB07129509 for ; Sun, 20 Nov 2016 19:27:39 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id n21so334819885qka.3 for ; Sun, 20 Nov 2016 19:27:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wLWW2Jpnbb5LoEDVbjgBknYhSFhMnzs5769sljD2TDI=; b=x0Ic9eDxWoDqNen37d68vxyBrL9fQuFZ0AqSP+qDtxXXardH6AU77kKSlD18bj9/Nc MsENZEhQaPmj2ruQfSfm+GB3HLQRb95tfZdw9TDHd9xEhkFs6dmgfTaDpDoqNyAISsUw erfcng3nzIk5fSiyMVUA7WVeJsDTUMBqLGQKcyce+mJfkJfQx9ld+3U+JCxRsUSAdIaO 05puo1JlsjdvdO5tW/i+E9yq7mv0u/17lEdTwFqWqOFJPKBYC/a/JTMeBcc9jyGgIk8x uejPEKaaXiwyA/WEi/PssqmdZfv/4gd+2RULc92sFL5U0nOeQY/c/GoTvC84GKJ13aJ4 W/vQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wLWW2Jpnbb5LoEDVbjgBknYhSFhMnzs5769sljD2TDI=; b=FTlz2XZC6ZixTE/271jqsWepHE1Niih0gShZdmkxnQZVJfJudjKVflOKNVO5qR9LUA GAOA1p3WyuQErStdxQ/en3gnjrrj7QsFaxQ3oeH+AUoR0B97QPFKoOUkH/vQTs+MJjYF tygOw6KoZ2CkZ3qUq8w2mZyBZnn+KtZQrCfGrqQBz10s1Zr4qOJ0kSI1vuR5SB23w7PA W5yEnk8Zj0flJ5e4auRyOmDPIu0PysLifUr7+b913bNGHgqN2CJZiXjNMZd4zFLu+2IP oEoCLmJo9ned7ow+QqX5pn9tVdO+5mJLRh984RGnVzQny8l4xuazsPLh+xMHJWGRM1Xp UYBQ== X-Gm-Message-State: AKaTC03IsF2wn/OLNFWhqZ7F9czzTOJSpeagDeI5L4z3YJkveN2fqpqmhj7R4n5lqMerZLFKdgK53xspST9Qtg== X-Received: by 10.55.99.141 with SMTP id x135mr12709907qkb.147.1479698858663; Sun, 20 Nov 2016 19:27:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Sun, 20 Nov 2016 19:27:37 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Mon, 21 Nov 2016 14:27:37 +1100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 03:27:41 -0000 On 21 November 2016 at 14:13, Eric Rescorla wrote: >> IMO, the compression methods section of ClientHello should be ignored as >> mentioned by Martin Rex. > > I'm not seeing any good reason for this. We don't want anyone to offer > compression and it's not > like it's difficult for 1.3 implementations to not offer it. I understand Martin Rex's rationale: we are effectively mandating a requirement on implementations of other versions of the protocol. However, I agree with ekr. We have - I think - consensus to forbid compression more broadly than just in TLS 1.3. It's a foot gun. And I don't believe that the foot gun is unique to the web case. For example, if you don't believe that mail could contain attacker-controlled data and secrets, then you haven't thought hard enough about all the ways mail can be used. Similarly, insert protocol of choice. Of course it's definitely true that someone loaded and cocked the footgun for the web. From nobody Sun Nov 20 19:44:50 2016 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 18A4A1296DA for ; Sun, 20 Nov 2016 19:44:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HK_RANDOM_ENVFROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.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 669Va1p8yxMj for ; Sun, 20 Nov 2016 19:44:46 -0800 (PST) Received: from COL004-OMC4S15.hotmail.com (col004-omc4s15.hotmail.com [65.55.34.217]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C3A51296B1 for ; Sun, 20 Nov 2016 19:44:46 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com ([65.55.34.201]) by COL004-OMC4S15.hotmail.com over TLS secured channel with Microsoft SMTPSVC(7.5.7601.23008); Sun, 20 Nov 2016 19:44:45 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UIGId6fvX1Ix01CTuKo4g+JSgsNHs6XKwMxR3io2aH0=; b=dWGWEYOjNwdYE2XMVWzdijx7QTuL2lHcJI+3UNvizjf2ZESyFmQ1BFsMIrsm4qqQU/wNuREa9HarkNpRoafKY0qd1KyVioRnx++fVyHrk4XmlKjGvtDCz3jUjM9tZjwNOnjCR/U+yl6+3Qw/jN1icCJmaKedaP1RV0sMgG7hE2S4VbhllBk4c2c43wCrXGdxMwubNMgnb1ZXSG1XzXbG3PQUnkbV+DF0qB99HK3Zf3Tv+3eNKuS01dw/p3jKLuuiJKhLA/lXBOPgT1y9PFnag+OXIWC4slTba0FdKGLdMCh4wUuQ/s9P18ZHsksEDGAZiZB+RUvT+9H7ep7R/vylLw== Received: from SN1NAM02FT009.eop-nam02.prod.protection.outlook.com (10.152.72.53) by SN1NAM02HT011.eop-nam02.prod.protection.outlook.com (10.152.73.6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.4; Mon, 21 Nov 2016 03:44:44 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com (10.152.72.57) by SN1NAM02FT009.mail.protection.outlook.com (10.152.73.32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.4 via Frontend Transport; Mon, 21 Nov 2016 03:44:44 +0000 Received: from BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) by BY2PR15MB0775.namprd15.prod.outlook.com ([10.164.171.11]) with mapi id 15.01.0721.017; Mon, 21 Nov 2016 03:44:44 +0000 From: Xiaoyin Liu To: "D. J. Bernstein" , "tls@ietf.org" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQ5Igw774AH9cm0yQtgfB3XzVGaDizAtm Date: Mon, 21 Nov 2016 03:44:44 +0000 Message-ID: References: , <20161121005612.1445.qmail@cr.yp.to> In-Reply-To: <20161121005612.1445.qmail@cr.yp.to> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: cr.yp.to; dkim=none (message not signed) header.d=none;cr.yp.to; dmarc=none action=none header.from=outlook.com; x-incomingtopheadermarker: OriginalChecksum:; UpperCasedChecksum:; SizeAsReceived:7446; Count:39 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [qCk05wJBp3QwAGkSeme5DigS2E7zDXNj] x-incomingheadercount: 39 x-eopattributedmessage: 0 x-microsoft-exchange-diagnostics: 1; SN1NAM02HT011; 5:jEcAMhfrf7xE/70lcmGcSD70Kxbzx25ul+GjDoptFWjJmIGE+XY1ejgaVwT7ma3NVKar4Tzzm9AYgYmbVrqmwEKS/NrElSIDLl6PBrvW3OfaG/SNf9a02LV2oB3maI62LUHSfiM7tQIkdNq7Di222A==; 24:psqxoA0W7F6oqK9Tq67s7neIT3maiiLpdupxMWiLeHnhxW4yZfVFRFmCSUKMLjqSBksTbvW4IE665F+LjcfUPm3c90b8n8mX4kBeCTgon94=; 7:D5k8jpKxjlxHqISBqH2H0rrOffs8MpEmsrEEhei0QzVcEVvNPRBcivxj20+50Px7guslkfSGR4iU5D6hcQ/nipuV5VLWWMBbN2wPVJqR96PypGTtaWUaffMBSKfVLEheSKH9DYD4HEsh0PdaHd+VWDCmFkSXBWA1h3J5MvRf5Alfpzi1W+skFAN5epjm3P2uLsTnQl0rpel3/xNPL5bxviH1oscgi9fF06wRGLhI4krsie4azf1VldYQ4jAPkt2x+NMqfdZmE+1qbn7XIqhkcNru6nPBE8mAN3j0YGTkDgLh/CbBF1U0vdSnReJeIZg/RMgVs9K/vf8IAxSWcfxpr9uBGxBgZv7uey3r74ZwT/w= x-forefront-antispam-report: EFV:NLI; SFV:NSPM; SFS:(10019020)(98900003); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1NAM02HT011; H:BY2PR15MB0775.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; x-ms-office365-filtering-correlation-id: c0112076-7c16-46c8-7b39-08d411c0bb7b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(1601124038)(1603103113)(1603101340)(1601125047); SRVR:SN1NAM02HT011; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(432015012)(82015046); SRVR:SN1NAM02HT011; BCL:0; PCL:0; RULEID:; SRVR:SN1NAM02HT011; x-forefront-prvs: 01334458E5 spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_BY2PR15MB0775FE7927F47E5B3DCB7507FFB50BY2PR15MB0775namp_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2016 03:44:44.1969 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1NAM02HT011 X-OriginalArrivalTime: 21 Nov 2016 03:44:45.0847 (UTC) FILETIME=[99F1F270:01D243A9] Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 03:44:48 -0000 --_000_BY2PR15MB0775FE7927F47E5B3DCB7507FFB50BY2PR15MB0775namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable +1 for =93TLS 2017=94 for all the four reasons given in the proposal. My overall preference is TLS 2017 > TLS 4 > TLS 2 or 2.0 > TLS 1.3. Best, Xiaoyin From: D. J. Bernstein Sent: Sunday, November 20, 2016 7:56 PM To: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* The messages on the list seem to be perfectly split between "TLS 1.3" and "TLS 4". I suspect that the "TLS 2017" idea will break this impasse: * it shares the fundamental advantage that led to the "TLS 4" idea; * it has the additional advantage of making the age obvious; * it eliminates the "4 sounds too much like 3" complaint; and * it eliminates the "where are TLS 2 and TLS 3?" complaint. Perhaps it's worth starting a poll specifically between "TLS 1.3" and "TLS 2017"? Or at least asking whether the new "TLS 2017" option would swing some previous opinions? Of course people who prioritize retaining the existing "TLS 1.3" mindshare will be just as unhappy with "TLS 2017" as with "TLS 4", but they'll get over it within a few years. :-) ---Dan _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_BY2PR15MB0775FE7927F47E5B3DCB7507FFB50BY2PR15MB0775namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

+1 for =93TLS 2017=94 for all the four reasons= given in the proposal.

 

My overall preference is TLS 2017 > TLS 4 > = TLS 2 or 2.0 > TLS 1.3.

 

Best,

Xiaoyin

 

From: D. J. Bernstein
Sent: Sunday, November 20, 2016 7:56 PM
To: tls@ietf.org
Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS*

 

The messages on the list seem to be perfectly spli= t between "TLS 1.3"
and "TLS 4". I suspect that the "TLS 2017" idea will br= eak this impasse:

   * it shares the fundamental advantage that led to the "TL= S 4" idea;
   * it has the additional advantage of making the age obvious;    * it eliminates the "4 sounds too much like 3" compl= aint; and
   * it eliminates the "where are TLS 2 and TLS 3?" com= plaint.

Perhaps it's worth starting a poll specifically between "TLS 1.3"= and
"TLS 2017"? Or at least asking whether the new "TLS 2017&quo= t; option would
swing some previous opinions?

Of course people who prioritize retaining the existing "TLS 1.3"<= br> mindshare will be just as unhappy with "TLS 2017" as with "T= LS 4", but
they'll get over it within a few years. :-)

---Dan

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
 --_000_BY2PR15MB0775FE7927F47E5B3DCB7507FFB50BY2PR15MB0775namp_-- From nobody Sun Nov 20 20:19:22 2016 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 3E11D126BF7 for ; Sun, 20 Nov 2016 20:19:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 J6l55WqoMsXZ for ; Sun, 20 Nov 2016 20:19:19 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09402129439 for ; Sun, 20 Nov 2016 20:19:18 -0800 (PST) Received: from [192.168.3.104] (unknown [124.189.98.244]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id D9E3422E1F3; Sun, 20 Nov 2016 23:18:59 -0500 (EST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Mark Nottingham In-Reply-To: Date: Mon, 21 Nov 2016 15:18:56 +1100 Content-Transfer-Encoding: quoted-printable Message-Id: <8CC62A55-C7E2-4B57-8159-F77AF7D36A8A@mnot.net> References: To: Sean Turner X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 04:19:21 -0000 I give the chairs my full support for whatever colour they wish to paint = this bikeshed. > On 18 Nov. 2016, at 1:12 pm, Sean Turner wrote: >=20 > At IETF 97, the chairs lead a discussion to resolve whether the WG = should rebrand TLS1.3 to something else. Slides can be found @ = https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr= 612-01.pdf. >=20 > The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this = decision on the list so please let the list know your top choice = between: >=20 > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 >=20 > by 2 December 2016. >=20 > Thanks, > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Mark Nottingham https://www.mnot.net/ From nobody Sun Nov 20 20:26:48 2016 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 2D8E212955E for ; Sun, 20 Nov 2016 20:26:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 BnzY17bCfj18 for ; Sun, 20 Nov 2016 20:26:44 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A15D1293E1 for ; Sun, 20 Nov 2016 20:26:44 -0800 (PST) Received: from vpro.lan (cpe-74-71-8-253.nyc.res.rr.com [74.71.8.253]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 7DFC2284B67 for ; Mon, 21 Nov 2016 04:26:43 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <20161121005612.1445.qmail@cr.yp.to> Date: Sun, 20 Nov 2016 23:26:42 -0500 Content-Transfer-Encoding: 7bit Message-Id: <03DE22AB-A805-45EC-8BCE-46AC17D501F4@dukhovni.org> References: <20161121005612.1445.qmail@cr.yp.to> To: tls@ietf.org X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org 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: Mon, 21 Nov 2016 04:26:46 -0000 > On Nov 20, 2016, at 7:56 PM, D. J. Bernstein wrote: > > Of course people who prioritize retaining the existing "TLS 1.3" > mindshare will be just as unhappy with "TLS 2017" as with "TLS 4", but > they'll get over it within a few years. :-) This worked well enough for IDNA2003 and IDNA2008 (the latter was finally published in 2010, and even that is not a problem). So I can get behind TLS 2017. I had even considered suggesting it, but did not at the time want to add more options to the mix. I think the risk of two TLS standards published in a single year is vanishingly low. And see no problems with "gaps" in the numbers. -- Viktor. From nobody Sun Nov 20 20:31:16 2016 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 5AFE9129572 for ; Sun, 20 Nov 2016 20:31:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWxhnqbD5x3p for ; Sun, 20 Nov 2016 20:31:13 -0800 (PST) Received: from mail-wj0-x22d.google.com (mail-wj0-x22d.google.com [IPv6:2a00:1450:400c:c01::22d]) (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 2ACF312956C for ; Sun, 20 Nov 2016 20:31:12 -0800 (PST) Received: by mail-wj0-x22d.google.com with SMTP id xy5so21681287wjc.0 for ; Sun, 20 Nov 2016 20:31:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=uKGPwAbxenFM1Y3TN18lRPaVx4RmnJbH+1C/aoPPH9c=; b=Vr2Vf2F6JusLd8fVt03IsIjpLEpM55P6gh41pccrBhhpVBOGsrHDIHjJ7S4eU07A/y 33UarNhneyzJFqQtwA7jgzu03zBo9HXx/JwZpdQBUfTzSYnOUcQvzK5uN9yJFaj6FA+5 8Nm+/wgsjOBX8g2ZXOa+6UI7wUNxQITMpHTdaDuTL5djiGlmt1RJE78NXop6Xg3pu4tI PCynUDgMlhmD2vXiTi5SpM4pRBln5B85RxR1ZgUQ4t1RyJHaB/7GKfET7yEwBm+x96cu nmbuCDIfBFiEwR9hecQ7d/FGMIb68Bj1mfD2PgvvdLg6/Yq2wYUpbecs15yOUwnFf+gE NUDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=uKGPwAbxenFM1Y3TN18lRPaVx4RmnJbH+1C/aoPPH9c=; b=NLrRZfzjYpi0mn3azdg8+0f0pfTR0ZXVWYFAqlK4U1sP6iELiMAbtyAVVE40GWA7kR tOYwx+3e7SM9X2eSC8I53Iuf8FJIFrrNXGOnsrQxAexZ84IMIxcJYneITYB0es5USir1 YfytREzqzhs5aqY07gFzX4A1rxl4wI/+F31CDlw8Ce4FvHBOedx4RS5AHZLzWSI/R/hS 9H9Gf0UEBKgWJda3rLK3QBlDSZ+c32asrSR8h/R0tx1sZSNUWvCPwyL07KfVE3XaQRQi pOmiV/r3gd6Zf4UrUQDHQzk20iWV3irsCrDlC1DwEFzWJfAxGk7CtMv3PaV1IHo5Sc4u rdMg== X-Gm-Message-State: AKaTC01/TsEE8Gn75dFPHB/LxL0VaV6dW/WQR7hn8nXz9LPg3VcS4Nzc2BDK+15DAs1C/A== X-Received: by 10.194.2.198 with SMTP id 6mr8907003wjw.51.1479702670701; Sun, 20 Nov 2016 20:31:10 -0800 (PST) Received: from [192.168.43.74] ([2.53.141.102]) by smtp.gmail.com with ESMTPSA id ua15sm22629530wjb.1.2016.11.20.20.31.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 20 Nov 2016 20:31:09 -0800 (PST) To: "Salz, Rich" , Sean Turner , "" References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <7462904085cc4a94914298af81157031@usma1ex-dag1mb1.msg.corp.akamai.com> <7de8f9da-8ab1-cfc2-00ad-9c91c7694174@gmail.com> <8394bafcd99344838d878b5e8cf5b524@usma1ex-dag1mb1.msg.corp.akamai.com> From: Yaron Sheffer Message-ID: <8262a7bf-6c19-0a23-9d0b-8f59344444aa@gmail.com> Date: Mon, 21 Nov 2016 06:31:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <8394bafcd99344838d878b5e8cf5b524@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 04:31:14 -0000 So the key schedule changed and therefore we think cross-version attacks are impossible. Have we also analyzed other protocols to ensure that cross protocol attacks, e.g. with SSH or IPsec, are out of the question? Put differently, algorithm designers gave us a cheap, easy to use tool to avoid a class of potential attacks. Why are we insisting on not using it? Thanks, Yaron On 20/11/16 17:33, Salz, Rich wrote: >> For those who missed CURDLE, could you please briefly explain why we don't >> need signature context in non-TLS areas. > > The one place we were concerned about attacks was in pre-hash signatures, and we made those a MUST NOT. And yes, your'e right, it's not relevant to TLS. > >> So why are we now saying that contexts are not needed even for TLS? > > I think because the key schedule changed. > > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz@jabber.at Twitter: RichSalz > > From nobody Sun Nov 20 20:59:47 2016 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 5EBB7129573 for ; Sun, 20 Nov 2016 20:59:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 GyqZFzkWkHIK for ; Sun, 20 Nov 2016 20:59:43 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99C411294A6 for ; Sun, 20 Nov 2016 20:59:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1479704382; x=1511240382; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=UBr/Xsm/aYyGVx+r521yQVHYVFoant9eMIaDNZHKEUw=; b=53n0YiFNCG9Dum27uf79OjJI4P64qfqSX/8qJmfX34lQ3nOqlLy1z7RJ hViKdgnwBAcyoQFP9Fn9B1vgZc88euT+KlHMIfT8g6e/jI50+flK9wDo0 HCwVaWNrgK7b/pjyWoUtGt0oPDpy8pbggVIPFJH5Ol1gIvbiBtIoSM+td jIm91EX/HUvgRetRCym2uaCpwrFh2jY9gUMzS/BSth+qne2SJVgvOznyc IRNeRemRBxZm7I3HJfIHxUHfT8Hq8J0gOXkPpi0JiHcUgx6UznfZRvXZ8 E8EGfkbTvfV23/YYdiI5bHkYp/5sbMQ7vt6cxBWSxdThIcR32P40tm5jx g==; X-IronPort-AV: E=Sophos;i="5.31,525,1473076800"; d="scan'208";a="116219770" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Nov 2016 17:59:40 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 21 Nov 2016 17:59:40 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Mon, 21 Nov 2016 17:59:40 +1300 From: Peter Gutmann To: Eric Mill , Filippo Valsorda Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQ2LAD667DaatoU6RNleDGo1T66Dh0tCAgAEOUVQ= Date: Mon, 21 Nov 2016 04:59:40 +0000 Message-ID: <1479704379387.25729@cs.auckland.ac.nz> References: <1479669457.3015489.793828961.121B4C8F@webmail.messagingengine.com>, In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 04:59:46 -0000 Eric Mill writes:=0A= =0A= >The near-term annoyance of renaming things by folks close to the WG, and t= he=0A= >chance of some confusion around the edges, seem like small issues compared= to=0A= >a positive investment in bending the sanity curve of the next 20 years of= =0A= >lazy enterprise decisions.=0A= =0A= +1.=A0 I was reading an article earlier today on a security web site (not a= =0A= general news site or even an IT news site but specifically a security web= =0A= site) where they mentioned that sensitive traffic wasn't SSL-protected.=A0 = Even=0A= the security people are still calling it SSL.=A0 So if you number it "4" or= =0A= "2017" it doesn't matter whether it's SSL or TLS, it's obvious that it's a= =0A= newer version than anything else out there.=0A= =0A= Peter.=0A= =0A= = From nobody Mon Nov 21 01:04:09 2016 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 C6489129889 for ; Mon, 21 Nov 2016 01:04:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mhgAAnMfg8oF for ; Mon, 21 Nov 2016 01:04:05 -0800 (PST) Received: from resqmta-po-08v.sys.comcast.net (resqmta-po-08v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:167]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C7D8129892 for ; Mon, 21 Nov 2016 01:03:50 -0800 (PST) Received: from resomta-po-10v.sys.comcast.net ([96.114.154.234]) by resqmta-po-08v.sys.comcast.net with SMTP id 8kVscDEkA2dNj8kVxc3HPr; Mon, 21 Nov 2016 09:03:49 +0000 Received: from [192.168.0.10] ([24.5.144.109]) by resomta-po-10v.sys.comcast.net with SMTP id 8kVwcHMGIgtO48kVwceI5i; Mon, 21 Nov 2016 09:03:49 +0000 Message-ID: <5832B873.4080608@brainhub.org> Date: Mon, 21 Nov 2016 01:03:47 -0800 From: Andrey Jivsov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfK3iWCB1afOmib3lsOkLRy4TA2i0FMmXzRKGCnr/0N6QJowQ4eRXUbNHaI0WX1rWDThrNwi0Hit/ttvzCPMkh1a0eCIDGZ+dMYk7U7P+FeRDGpC8EJyF VJ3Tak+sWg+v6lFJnO1wyOD8NqKeRKP2Cjm6NnpYrx8/PshbANJ1nHQe Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 09:04:08 -0000 On 11/17/2016 06:12 PM, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should rebrand TLS1.3 to something else. Slides can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. > ... TLS 4. TLS 1.3 introduces major changes to message flow and substantial redesign of crypto. I will respectfully remind that earlier this year the WG has made a decision to break backward compatibility with large number of devices by rejecting an option to extend allowed in TLS 1.3 RSA PKCS#1.5 signature padding scheme to all portions of the handshake. The solution was that these peers must keep using TLS 1.2 https://www.ietf.org/mail-archive/web/tls/current/msg19360.html . Changes of this magnitude are not typically associated with a "dot" release. + what other said on confusion with SSL. I don't see this one as a big deal, but I will go with the consensus of "4.0" v.s "2.0". "1.3" is the worst choice here. From nobody Mon Nov 21 10:23:27 2016 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 00B67129B2F for ; Mon, 21 Nov 2016 10:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.022 X-Spam-Level: X-Spam-Status: No, score=-2.022 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=microsoft.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 yPrzGQyvCJmN for ; Mon, 21 Nov 2016 10:23:24 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0093.outbound.protection.outlook.com [104.47.40.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49EEE1296B7 for ; Mon, 21 Nov 2016 10:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oEnh3DuLPfWEKlMhhvk76GbWrJfCtkHchWtYYuMbNVI=; b=De8XfjOj7TOI18UczVQAMWxJVb9cxAjJokDopS/9lNHXzyDYeuIVYuOq8JTQ09o8m31oHtx6cBDdcdYamvEeDgx4tWm3EJKI7RzujXywdWsqzdj1Bo+UD/Y72gP9B3zKD91L7bRWC90M/lTsUlqaKT1o8SJwCKiZJa7lrHct5i8= Received: from BN3PR0301MB0836.namprd03.prod.outlook.com (10.160.154.146) by BN3PR0301MB0835.namprd03.prod.outlook.com (10.160.154.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.693.12; Mon, 21 Nov 2016 18:23:20 +0000 Received: from BN3PR0301MB0836.namprd03.prod.outlook.com ([10.160.154.146]) by BN3PR0301MB0836.namprd03.prod.outlook.com ([10.160.154.146]) with mapi id 15.01.0693.009; Mon, 21 Nov 2016 18:23:20 +0000 From: Andrei Popov To: Peter Gutmann , Ilari Liusvaara Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFnfYxD1l3raU+THHLUgHfRNqDeqWsAgAAMewCAACvVgIAAuIAAgAQpaVA= Date: Mon, 21 Nov 2016 18:23:20 +0000 Message-ID: References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz>, <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> <1479523253827.80996@cs.auckland.ac.nz> In-Reply-To: <1479523253827.80996@cs.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:5::1d2] x-microsoft-exchange-diagnostics: 1; BN3PR0301MB0835; 7:m24J18CF00AqszqrC0Scl4JvCirIzM9nePjiOxb82fGptPddDzphvnnNm39NcdH/qGKIge1/GKw/FUpwsmWQEBWr28rYXvL61H4MbFFjREWjnnXpH8lSMgr9gKt8BRSU6jno+xT5hL9dU8jjrCj5K81sGwQrwCN7In3U3yP6SiJ8ObSZ6maR0gMQLBiN+2QEWnUkw9jYTJraQUpziiafo9RDHRaHdcBnFr12FRf60jV9XeajMrC7G3kpk7Qggsw0pbTFwn/ACU7Nc7/wFE+N9ab1B/2y4q+YOe+Q4XSMfG/4tCHObg0jFcl6d3BrTGWp0Grj9FnUYM8GqPxWUEnqg+DhW6fQHDRGvHBbBwC4etAI7OGKHNKIUgy/CCTrST1j x-ms-office365-filtering-correlation-id: aefade79-0128-4bb0-8f76-08d4123b78de x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0301MB0835; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040307)(6060326)(6045199)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(6046074)(6061324)(6042181); SRVR:BN3PR0301MB0835; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0301MB0835; x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(13464003)(377454003)(199003)(7846002)(229853002)(3660700001)(2900100001)(5005710100001)(74316002)(86612001)(8990500004)(81156014)(3280700002)(99286002)(101416001)(7736002)(8676002)(10290500002)(102836003)(6116002)(9686002)(6506003)(2906002)(4326007)(68736007)(106116001)(105586002)(54356999)(106356001)(38730400001)(7696004)(8936002)(81166006)(5660300001)(305945005)(77096005)(97736004)(122556002)(92566002)(76176999)(50986999)(10090500001)(5001770100001)(189998001)(33656002)(2950100002)(87936001)(76576001)(93886004)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0835; H:BN3PR0301MB0836.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2016 18:23:20.2551 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0301MB0835 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 18:23:26 -0000 Peter has some excellent points here (although I would prefer "TLS 2.0"). Perhaps the "re-branders" are losing votes and hums because we're fragmente= d into numerous camps. With this in mind, I'm voting in favor of any re-branding of TLS 1.3 where = the protocol name remains "TLS" and major version becomes > 1. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Peter Gutmann Sent: Friday, November 18, 2016 6:41 PM To: Ilari Liusvaara Cc: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* Replying to several messages at once to save space: Ilari Liusvaara: >One can downnegotiate TLS 1.3 to TLS 1.2. Ah, you're obviously a fan of Steve Wozniak humour. When someone asked him= whether it was possible to upgrade from an Apple II+ to an Apple IIe, he s= imilarly said "yes, you unplug the power cable from the II+, throw it away,= and plug the IIe into the newly-vacated power cable". Christian Huitema: >I prefer TLS 1.3, because is signals continuity with the ongoing TLS=20 >deployment efforts. Maybe it's just me, but wouldn't the fact that they're both called TLS sort= of indicate that there's continuity there? Dave Kern: >I'm in favor of TLS 4, and ignoring the minor version number (in the=20 >friendly text string, not the protocol field) moving forward. That's actually a good point, "TLS 4" provides a single, clean number for p= eople to remember. Even a CTO or auditor should be able to get that one ri= ght without having to look up a table in a book to see that 1.3 > v3. Peter. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Nov 21 10:43:36 2016 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 9200E1294AA for ; Mon, 21 Nov 2016 10:43:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 tkNqyChD9LdS for ; Mon, 21 Nov 2016 10:43:32 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 4A02F128B37 for ; Mon, 21 Nov 2016 10:43:32 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B53DC433408; Mon, 21 Nov 2016 18:43:31 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 9F20C433401; Mon, 21 Nov 2016 18:43:31 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479753811; bh=2nM7XXPIiL6fgD6QSdWQZrujK0uYC9YxVwyh10XwKto=; l=160; h=From:To:CC:Date:References:In-Reply-To:From; b=eZ3Nv0jZxwPIxVx9MHFdNWxkyFVGz+NWvBBbjbpgseg6cUIjE6ySkBbJ1zdjpD/uT 9APq+kHFvYEREgyjoAb64yMHUwPk+n74AwGrryXKgFn90Fy3lDn6FaY/tXy0L1e9bJ CwgSRJaLMaCxgBD47CoKTZ8LDlMpLqV1kGzbDPbU= Received: from email.msg.corp.akamai.com (usma1ex-cas1.msg.corp.akamai.com [172.27.123.30]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 9A90D1FC90; Mon, 21 Nov 2016 18:43:31 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb4.msg.corp.akamai.com (172.27.123.104) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 21 Nov 2016 13:43:31 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 21 Nov 2016 13:43:30 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Mon, 21 Nov 2016 13:43:31 -0500 From: "Salz, Rich" To: Andrei Popov , Peter Gutmann , Ilari Liusvaara Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9yvv3al+6E0mEp3NhmRhrEqDe/T0AgAAMegCAACvWgIAAuH8AgAQr7gD//7HG4A== Date: Mon, 21 Nov 2016 18:43:30 +0000 Message-ID: References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz>, <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> <1479523253827.80996@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.115] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 18:43:34 -0000 > With this in mind, I'm voting in favor of any re-branding of TLS 1.3 wher= e the > protocol name remains "TLS" and major version becomes > 1. Me too. From nobody Mon Nov 21 10:45:12 2016 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 071CA12944E for ; Mon, 21 Nov 2016 10:45:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PyAa-8zePUPu for ; Mon, 21 Nov 2016 10:45:10 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 CD729128B37 for ; Mon, 21 Nov 2016 10:45:10 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id b126so132813255oia.2 for ; Mon, 21 Nov 2016 10:45:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sE3HI+WM8zVdxuAX+3QSLA3Y/dLi+LkRM+5ttw4Vfm0=; b=afG7/akUUd/vkmyl1Myaz9AcJkQ9aJrlVjtFBUPvn4XTF4pWT7CGVi/owRUP7wKUr1 JJLTxUFuiyrKTDRyC+jJmEM7JV76FB3y/zkfqBc+r6hEzawyY91S8HLSzEEm/Y8ohdOD B6t8ndLHU/KVp6OIEpQcMAhITgZ1o6b9WgB2HKYFtbOMIXuR1NCQIyBzEfTcSIMaCq+b cEklYlflnK45HSUSNClMTRSG2MJ/MM8++KD19wKYVjYirAnuSVxI7TL29/fsT49nfX72 k7mbaxtHNdb5ShgzUKEFAlWWdsNPZceT1+9+ynMMLYhKtq/Y8LlG5pfQUd0J1w5+e1TQ IJEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sE3HI+WM8zVdxuAX+3QSLA3Y/dLi+LkRM+5ttw4Vfm0=; b=a6VPgGL3PQjdKfYYIsVtPQdJB63AEgmS8nLQadxPP0xSG+IDkkS15rcUboBzz0vo9j FQOdjhtCwKDnwVMQx2O6x+P5YfvrRD6DtpuMR9KK6V9ftdfdizakftubIFkOMPS2mFB4 SDDzewp/ob/G7Ltyzt0o/xaxZKnOQYMOc56WvPQHp9di8/tBcvFA7m61RItOjXL+BzdI jxMEUJ0kJGxOx4BOYn9UFuQenTvfQ3VEY4GFIH1o+p159yYLs8LLFF0m+eqGc4WtT11L eXSjZAbW72rYP32VvmInY28JAL3+hXAyDtWmr8GYD4DzuwzCqtfkBBSxkNt1GBV1f+0c BWkQ== X-Gm-Message-State: AKaTC01XOz1kqM2Z/KlfyhUdyzl6MUDPWhsRDyo/0uQA2gG0L7VoVX6nr8Fe4zosFxpcX1aKcVyjc/6WduJ7lA== X-Received: by 10.157.16.70 with SMTP id o6mr9453756oto.101.1479753910192; Mon, 21 Nov 2016 10:45:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.202.245.144 with HTTP; Mon, 21 Nov 2016 10:45:09 -0800 (PST) In-Reply-To: References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz> <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> <1479523253827.80996@cs.auckland.ac.nz> From: Dmitry Belyavsky Date: Mon, 21 Nov 2016 21:45:09 +0300 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a11413ccc2c0e770541d40e63 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 18:45:12 -0000 --001a11413ccc2c0e770541d40e63 Content-Type: text/plain; charset=UTF-8 Hello, On Mon, Nov 21, 2016 at 9:43 PM, Salz, Rich wrote: > > > With this in mind, I'm voting in favor of any re-branding of TLS 1.3 > where the > > protocol name remains "TLS" and major version becomes > 1. > > Me too. > > +1 -- SY, Dmitry Belyavsky --001a11413ccc2c0e770541d40e63 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,

On Mon, Nov 21, 2016 at 9:43 PM, Salz, Rich <rsalz@akamai.com>= wrote:

> With this in mind, I'm voting in favor of any re-branding of TLS 1= .3 where the
> protocol name remains "TLS" and major version becomes > 1= .

Me too.

+= 1=C2=A0


--
SY, Dmitry Belyavsky
--001a11413ccc2c0e770541d40e63-- From nobody Mon Nov 21 11:03:02 2016 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 2B448128B37; Mon, 21 Nov 2016 11:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.498 X-Spam-Level: X-Spam-Status: No, score=-8.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=usbank.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 PfaSGXU9g9nZ; Mon, 21 Nov 2016 11:02:55 -0800 (PST) Received: from mail9.usbank.com (mail9.usbank.com [170.135.218.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C8DEB1296ED; Mon, 21 Nov 2016 11:02:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=usbank.com; i=@usbank.com; q=dns/txt; s=TrustUS; t=1479754974; x=1511290974; h=in-reply-to:references:to:cc:mime-version:subject: message-id:from:date; bh=hl6VEiAAinMNaiLbzixsUMXVwbxdjHgKmHZ9JvTZrzI=; b=dLjjmt0P3npxmVifWHWnhNX4kIT8SvocP83xZg2ew1VAGcF2cN9QzyDy U/snh30EcTlHNvSm2n07uemnYS7MPN81L3pCIAG9UZZrT0Z6QYXMhU5uL wiiBIioPTGfDas0Nf5caP6ca06ypL4+XFXOBEbaKcJ4W6jjWx6oOnXjrH g=; Received: from unknown (HELO vmaksa69901cdj.us.bank-dns.com) ([156.36.214.214]) by mail9.usbank.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Nov 2016 13:02:53 -0600 X-Loop1: 1 X_fileSizes: None In-Reply-To: References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz>, <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> <1479523253827.80996@cs.auckland.ac.nz> To: "Salz, Rich" MIME-Version: 1.0 X-KeepSent: 5E21709D:146C3B11-86258072:0067CC21; type=4; name=$KeepSent X-Mailer: IBM Notes Release 9.0.1FP5 SHF106 December 12, 2015 Message-ID: From: darin.pettis@usbank.com Date: Mon, 21 Nov 2016 13:02:52 -0600 X-MIMETrack: Serialize by Router on EPEM104/MN/Servers/USB(Release 9.0.1FP6 HF273|August 01, 2016) at 11/21/2016 01:02:52 PM, Serialize complete at 11/21/2016 01:02:52 PM Content-Type: multipart/alternative; boundary="=_alternative 0068A21086258072_=" Archived-At: Cc: TLS , "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 19:03:01 -0000 This is a multipart message in MIME format. --=_alternative 0068A21086258072_= Content-Type: text/plain; charset="US-ASCII" Hello, On Mon, Nov 21, 2016 at 9:43 PM, Salz, Rich wrote: > With this in mind, I'm voting in favor of any re-branding of TLS 1.3 where the > protocol name remains "TLS" and major version becomes > 1. I originally hummed for 1.3 in the room as that is what people (that are currently aware of it) know it by. However, as the new standard goes out into the world, a major revision number seems appropriate to recognize the significant changes that have gone into it. +1 Darin Pettis U.S. BANCORP made the following annotations --------------------------------------------------------------------- Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation. --------------------------------------------------------------------- --=_alternative 0068A21086258072_= Content-Type: text/html; charset="US-ASCII" Hello,

On Mon, Nov 21, 2016 at 9:43 PM, Salz, Rich <rsalz@akamai.com> wrote:

> With this in mind, I'm voting in favor of any re-branding of TLS 1.3 where the
> protocol name remains "TLS" and major version becomes > 1.
I originally hummed for 1.3 in the room as that is what people (that are currently aware of it) know it by.  However, as the new standard goes out into the world, a major revision number seems appropriate to recognize the significant changes that have gone into it.  

+1
Darin Pettis

U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains information that is, or may be, covered by electronic communications privacy laws, and is also confidential and proprietary in nature. If you are not the intended recipient, please be advised that you are legally prohibited from retaining, using, copying, distributing, or otherwise disclosing this information in any manner. Instead, please reply to the sender that you have received this communication in error, and then immediately delete it. Thank you in advance for your cooperation.

--------------------------------------------------------------------- --=_alternative 0068A21086258072_=-- From nobody Mon Nov 21 11:22:52 2016 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 6F89E129B77 for ; Mon, 21 Nov 2016 11:22:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.402 X-Spam-Level: X-Spam-Status: No, score=-1.402 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=no 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 t--TyBv6qKib for ; Mon, 21 Nov 2016 11:22:50 -0800 (PST) Received: from gproxy1.mail.unifiedlayer.com (gproxy1-pub.mail.unifiedlayer.com [69.89.25.95]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AB6A129430 for ; Mon, 21 Nov 2016 11:14:41 -0800 (PST) Received: from cmgw3 (cmgw4 [10.0.90.84]) by gproxy1.mail.unifiedlayer.com (Postfix) with ESMTP id 4CF4617654C for ; Mon, 21 Nov 2016 12:14:39 -0700 (MST) Received: from box514.bluehost.com ([74.220.219.114]) by cmgw3 with id AjEb1u00P2UhLwi01jEeqS; Mon, 21 Nov 2016 12:14:39 -0700 X-Authority-Analysis: v=2.1 cv=K/+xQUmI c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=L24OOQBejmoA:10 a=oDKxhSPaUbOkgnclzy0A:9 a=QEXdDO2ut3YA:10 a=bAjXtAQy-F4A:10 Received: from [173.224.162.79] (port=48319 helo=[192.168.93.253]) by box514.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from ) id 1c8u31-0003Yy-4h for tls@ietf.org; Mon, 21 Nov 2016 12:14:35 -0700 To: IETF TLS WG From: =JeffH Message-ID: <2f776cf5-45b7-a382-28c4-2cd066336e0d@KingsMountain.com> Date: Mon, 21 Nov 2016 11:14:33 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box514.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - KingsMountain.com X-BWhitelist: no X-Source-IP: 173.224.162.79 X-Exim-ID: 1c8u31-0003Yy-4h X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.93.253]) [173.224.162.79]:48319 X-Source-Auth: jeff.hodges+kingsmountain.com X-Email-Count: 1 X-Source-Cap: a2luZ3Ntb3U7a2luZ3Ntb3U7Ym94NTE0LmJsdWVob3N0LmNvbQ== Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 19:22:51 -0000 In the room last week, I hummed for "TLS 4". that said, I overall agree with Andrei's sentiment.. > I'm voting in favor of any re-branding of TLS 1.3 where the > protocol name remains "TLS" and major version becomes > 1. HTH, =JeffH From nobody Mon Nov 21 11:34:08 2016 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 942BE129781 for ; Mon, 21 Nov 2016 11:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 wyN5bOKF3JJV for ; Mon, 21 Nov 2016 11:34:05 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 10B15129430 for ; Mon, 21 Nov 2016 11:34:04 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 7C3C1443113; Mon, 21 Nov 2016 19:34:04 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 66706443102; Mon, 21 Nov 2016 19:34:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479756844; bh=ZNcbtt5YUpz0zSFkQLuUCUIc9kvOzt+sA1WkQXy8qJw=; l=245; h=From:To:Date:References:In-Reply-To:From; b=nE+eNhwyof/z0kXY/w4N90T7uu/j+t8+LaGe/Hvb9TLBtCk03K+5kNE/JUR4hVRsd BRXTdJExx+WzGB39+qWHPLAKU4EOYoz79I8EZ3+9LXPZlJ/DezOoG1ajJlSuq2VMdE XQI+Z2VxOvhpkm72qAr8PuapmWGzijlBLjjUsqLM= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 62F201FC8C; Mon, 21 Nov 2016 19:34:04 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 21 Nov 2016 14:34:03 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 21 Nov 2016 14:34:03 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Mon, 21 Nov 2016 14:34:04 -0500 From: "Salz, Rich" To: =JeffH , IETF TLS WG Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSRCt9yvv3al+6E0mEp3NhmRhrEqDj0xVQ Date: Mon, 21 Nov 2016 19:34:03 +0000 Message-ID: <66622e93160d4670b4a425b2c93ea27c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2f776cf5-45b7-a382-28c4-2cd066336e0d@KingsMountain.com> In-Reply-To: <2f776cf5-45b7-a382-28c4-2cd066336e0d@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.115] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 19:34:07 -0000 Do "about:config" in firefox and look for TLS: security.tls.version.max default integer 3 And then perhaps look at http://kb.mozillazine.org/Security.tls.version.* (= yes the star is part of the URL) EVEN MOZILLA can't get it "right." From nobody Mon Nov 21 11:51:17 2016 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 78AF11296DC for ; Mon, 21 Nov 2016 11:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8HZ8a1v0Lwa0 for ; Mon, 21 Nov 2016 11:51:14 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (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 F13A512942F for ; Mon, 21 Nov 2016 11:51:13 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id u144so132644wmu.0 for ; Mon, 21 Nov 2016 11:51:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dPY2gAamfce9sN0F+AJKaazZgewNVTf2OR00lukMlis=; b=DbRkwdrSk6XEjcdSw+XE74rLEQZXqYt3+ei2c38YSzrCC3Wmxe40k0WrGOL6pyWNGL syodJgQ6jAIR66o8rukZaqpKdWpZFjQJllHOKbNxecIgB16wKbHIcFlpZ9O/pd/rmIcZ nrMtF+A4I5mQ+GMP6zuesh94o7ANSfTSN1IwQeoj0nrtyk3y67s6J3X57lIWsFB/wHVk m7sH0xzK+/EJ0yfCes4DLp5d2citV/3qjS+/BJidNPAsTwimDkAb5vvKFDGgXaEdGIcR WhBuoIEtOU9i0JML7GsCGMQU0dgHbQbWuztS7jLb1NzEksA6xYKLFbQo4GYyIwSJqRdr fgqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dPY2gAamfce9sN0F+AJKaazZgewNVTf2OR00lukMlis=; b=S21McG0rF/+4J+ePbCGS/S3byjecXcClEWouc4VTG+xSfqVv+9jma04uZ6zZJYbbQf 4V5L+KLuN7gmpZ8N607KchiYP4jcUApoqpkCpQTIY4PKphNL+R9z30S55obwKZDsPsei YMWt3yRoGon9gCruJuWzjV0AX+2R3k+6Qs2wT+zMu2AsO8BARf4dRJpewa8wW23t2vVg ZQBJMgtty3E5q1jfZueIrCC4QlPV1QW8KgJPLlosdT3DUfJ8vgrKXAwiy5VdqWcJ9gPb bGLJs59uAbouKlL1jCcMol1Vn0H5gW+e7O5dEoQtyILPfxmo3xvWiqLgH2BZgLhGmzrw 01iw== X-Gm-Message-State: AKaTC00YC2HVxg/RKpEpv+CkhaZjfGbvXY7O2VVV5oXyGIWqJ23Qxx/W5q3knc6dbH0bbA== X-Received: by 10.28.62.77 with SMTP id l74mr15627756wma.37.1479757872506; Mon, 21 Nov 2016 11:51:12 -0800 (PST) Received: from [192.168.1.14] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id ab10sm26677613wjc.45.2016.11.21.11.51.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 21 Nov 2016 11:51:11 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: Date: Mon, 21 Nov 2016 21:51:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz> <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> <1479523253827.80996@cs.auckland.ac.nz> To: Rich Salz X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 19:51:15 -0000 > On 21 Nov 2016, at 20:43, Salz, Rich wrote: >=20 >=20 >> With this in mind, I'm voting in favor of any re-branding of TLS 1.3 = where the >> protocol name remains "TLS" and major version becomes > 1. >=20 > Me too. Agree From nobody Mon Nov 21 12:01:03 2016 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 59DED12944B for ; Mon, 21 Nov 2016 12:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 EE1011MWf1Z3 for ; Mon, 21 Nov 2016 12:00:59 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 8DEFA129B80 for ; Mon, 21 Nov 2016 12:00:56 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id a10so221646137ywa.3 for ; Mon, 21 Nov 2016 12:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PeOWAD8gP0wGxnLPgyPVgWpuSCUVvgQIHrNzkbsKpbA=; b=YFoyG0LzDCqg1TiE1ymOiKhHxbu7+S1+doVo7ok7CWYgBhlb+8k1TgI6NckoY0Rpjo /yVgVmLw0blk6CiqZsYzFFWqE4u+T5jsy3HNEuK1pEyveWXu0BQS5JQ+PjN2LXh53pNu Kn3nhkMYvkh8sW4Kkmyuo/OYMZvpf6KSyHs47wowNj1tWO7LmD1LDJjVg4OoAl5WiXne zjBw8u51cgc2I7Xwwb6kjcseajhZ+FZDsnKVDJyfYbTk4UC9vZzyvEGAidErWUYGEZxv AvbtMjrD76iEUUZ3ceS8ASgjzCBV4nd/A3bpbt6AdzmFQ690hdsnJwX9FBgnhkffCdNf A2Ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PeOWAD8gP0wGxnLPgyPVgWpuSCUVvgQIHrNzkbsKpbA=; b=bixJdgSa76LMJm4xz51VU5ZrU4td3BM0/GPa9ErOOtIFaJuMDWPhy389K3nEuWOO45 lSgQQKAnvGgd7yK6xPa0enuskife9dbEdQyY1sxw7/DdjNvf3CVagjZr0tHpxiUlrsgi ngvaII8y2LycWUY8kYetOrGXIaAKSbdEMxiNczJw36dhqLGertJoF82gMTjyx4yu1Y6s jaZBeRVJuSTINOQ4d/sLv0mG/vke8Zzdl1PM4Ra7OHwtojbZmUMxc4lYgnirWeHn1quf zpooi11IzHX9ujoqsOwrUjVqRsqUDAxFHYFvumwZMRxN5b6Dpw75pMs4KZfdk95JAZoV cvag== X-Gm-Message-State: AKaTC02UWushuQmQSENvhjgo3MwN2sXtpMQvrHMY996DpH2IC9nuVyBBwz7pdv+0W1S/NJlfHRkr2kAcoO794Q== X-Received: by 10.129.108.216 with SMTP id h207mr16295712ywc.52.1479758455759; Mon, 21 Nov 2016 12:00:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 21 Nov 2016 12:00:14 -0800 (PST) In-Reply-To: <66622e93160d4670b4a425b2c93ea27c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2f776cf5-45b7-a382-28c4-2cd066336e0d@KingsMountain.com> <66622e93160d4670b4a425b2c93ea27c@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Mon, 21 Nov 2016 12:00:14 -0800 Message-ID: To: "Salz, Rich" Content-Type: multipart/alternative; boundary=001a114dd36e1c29180541d51d12 Archived-At: Cc: IETF TLS WG Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 20:01:01 -0000 --001a114dd36e1c29180541d51d12 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 21, 2016 at 11:34 AM, Salz, Rich wrote: > Do "about:config" in firefox and look for TLS: > security.tls.version.max default integer 3 > > And then perhaps look at http://kb.mozillazine.org/Security.tls.version.* > (yes the star is part of the URL) > > EVEN MOZILLA can't get it "right." > You should be reluctant to draw too many conclusions from a field which you can only access by clicking through a big scary warning that you are voiding your warranty: https://techjourney.net/media/2015/03/firefox-about-config-warning.png -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dd36e1c29180541d51d12 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On M= on, Nov 21, 2016 at 11:34 AM, Salz, Rich <rsalz@akamai.com> w= rote:
Do "about:c= onfig" in firefox and look for TLS:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 security.tls.version.max=C2=A0 =C2=A0 =C2=A0def= ault=C2=A0 =C2=A0integer=C2=A0 3

And then perhaps look at http://kb.mozillazine.org/<= wbr>Security.tls.version.* (yes the star is part of the URL)

EVEN MOZILLA can't get it "right."

<= /div>
You should be reluctant to draw too many conclusions from a field= which you can only
access by clicking through a big scary warnin= g that you are voiding your warranty:

http= s://techjourney.net/media/2015/03/firefox-about-config-warning.png
<= /div>

-Ekr
=C2=A0

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114dd36e1c29180541d51d12-- From nobody Mon Nov 21 12:02:25 2016 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 30098129B80 for ; Mon, 21 Nov 2016 12:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 TvwhAACQVhL3 for ; Mon, 21 Nov 2016 12:02:22 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB81129B8C for ; Mon, 21 Nov 2016 12:02:20 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D0144443108 for ; Mon, 21 Nov 2016 20:02:19 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id BA2C0443114 for ; Mon, 21 Nov 2016 20:02:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479758539; bh=riIhp675jnC47vZ+PiuiNG9ZGyOaGwjqJd1P9NAYNRU=; l=5879; h=From:To:Date:References:In-Reply-To:From; b=UUMTUxqHg6hjYVOf/3QgqZMeQdqmucxM/MXhMRrGr7Yjy3bJIL2i9n1UzZeqQgJnO Ueb6YvqUPp095d4GGkj8CIcdsO2O/n3cUbPOqWjGs+B9XgT4E3IaEWGdvlFzil8l8P cRmjArpCQkIV81WoS3yqXTsbYYt0ddcSeUr86Zkg= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id B69BB1FC86 for ; Mon, 21 Nov 2016 20:02:19 +0000 (GMT) Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com (172.27.123.105) by usma1ex-dag1mb5.msg.corp.akamai.com (172.27.123.105) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 21 Nov 2016 15:02:19 -0500 Received: from USMA1EX-DAG1MB5.msg.corp.akamai.com ([172.27.123.105]) by usma1ex-dag1mb5.msg.corp.akamai.com ([172.27.123.105]) with mapi id 15.00.1178.000; Mon, 21 Nov 2016 15:02:19 -0500 From: "Short, Todd" To: "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUF9vC8mWeXZn0m3UATlS6IqRaDe/T0AgAAMegCAACvWgIAAuH8AgAQr7gCAAAWjAIAAEuUAgAADHwA= Date: Mon, 21 Nov 2016 20:02:18 +0000 Message-ID: References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz> <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> <1479523253827.80996@cs.auckland.ac.nz> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.113] Content-Type: multipart/alternative; boundary="_000_A101A351B70A49A095A03DEE467325F5akamaicom_" MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 20:02:25 -0000 --_000_A101A351B70A49A095A03DEE467325F5akamaicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhyb3dpbmcgbXkgaGF0IGludG8gdGhlIHJpbmcsIHRoZSBiYXNpYyByZWNvcmQgcHJvdG9jb2wg aGFzIG5vdCBjaGFuZ2VkLg0KDQpJZiBhbnl0aGluZywgd2hhdCBpcyBjdXJyZW50bHkgcmVmZXJy ZWQgdG8gYXMgVExTdjEuMyBpcyByZWFsbHkganVzdCBhIG1ham9yIHVwZGF0ZSB0byB0aGUgaGFu ZHNoYWtlIG1lc3NhZ2VzLg0KDQpJZiB0aGUgcmVjb3JkIHByb3RvY29sIHdlcmUgdG8gY2hhbmdl IHRvIHVzZSBhIHNhbmUgNC1ieXRlIGhlYWRlciAod2hpY2ggSSBwcm9wb3NlZCBtYW55IG1vbnRo cyBhZ28pLCB0aGVuIEkgdGhpbmsgdGhhdCBjYWxsaW5nIGl0IFRMU3Y0IG9yIGVxdWl2YWxlbnQg d291bGQgYmUgYXBwcm9wcmlhdGUuDQoNCkF0IHRoaXMgcG9pbnQsIEnigJlkIHByZWZlciB0byBr ZWVwIGl0IFRMU3YxLjMsIHNpbmNlIEkgZG9u4oCZdCBjb25zaWRlciB0aGlzIGEgc2lnbmlmaWNh bnQgdXBkYXRlIHRvIHRoZSBwcm90b2NvbC4NCi0tDQotVG9kZCBTaG9ydA0KLy8gdHNob3J0QGFr YW1haS5jb208bWFpbHRvOnRzaG9ydEBha2FtYWkuY29tPg0KLy8gIk9uZSBpZiBieSBsYW5kLCB0 d28gaWYgYnkgc2VhLCB0aHJlZSBpZiBieSB0aGUgSW50ZXJuZXQuIg0KDQpPbiBOb3YgMjEsIDIw MTYsIGF0IDI6NTEgUE0sIFlvYXYgTmlyIDx5bmlyLmlldGZAZ21haWwuY29tPG1haWx0bzp5bmly LmlldGZAZ21haWwuY29tPj4gd3JvdGU6DQoNCg0KT24gMjEgTm92IDIwMTYsIGF0IDIwOjQzLCBT YWx6LCBSaWNoIDxyc2FsekBha2FtYWkuY29tPG1haWx0bzpyc2FsekBha2FtYWkuY29tPj4gd3Jv dGU6DQoNCg0KV2l0aCB0aGlzIGluIG1pbmQsIEknbSB2b3RpbmcgaW4gZmF2b3Igb2YgYW55IHJl LWJyYW5kaW5nIG9mIFRMUyAxLjMgd2hlcmUgdGhlDQpwcm90b2NvbCBuYW1lIHJlbWFpbnMgIlRM UyIgYW5kIG1ham9yIHZlcnNpb24gYmVjb21lcyA+IDEuDQoNCk1lIHRvby4NCg0KQWdyZWUNCg0K DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1h aWxpbmcgbGlzdA0KVExTQGlldGYub3JnPG1haWx0bzpUTFNAaWV0Zi5vcmc+DQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0KDQo= --_000_A101A351B70A49A095A03DEE467325F5akamaicom_ Content-Type: text/html; charset="utf-8" Content-ID: <7F5C4D0444CBB3468C7E0446ED500FEB@akamai.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsiIGNsYXNzPSIiPg0KVGhyb3dpbmcgbXkgaGF0IGludG8g dGhlIHJpbmcsIHRoZSBiYXNpYyByZWNvcmQgcHJvdG9jb2wgaGFzIG5vdCBjaGFuZ2VkLg0KPGRp diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+SWYgYW55dGhp bmcsIHdoYXQgaXMgY3VycmVudGx5IHJlZmVycmVkIHRvIGFzIFRMU3YxLjMgaXMgcmVhbGx5IGp1 c3QgYSBtYWpvciB1cGRhdGUgdG8gdGhlIGhhbmRzaGFrZSBtZXNzYWdlcy4NCjxkaXYgY2xhc3M9 IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPklmIHRoZSByZWNvcmQgcHJv dG9jb2wgd2VyZSB0byBjaGFuZ2UgdG8gdXNlIGEgc2FuZSA0LWJ5dGUgaGVhZGVyICh3aGljaCBJ IHByb3Bvc2VkIG1hbnkgbW9udGhzIGFnbyksIHRoZW4gSSB0aGluayB0aGF0IGNhbGxpbmcgaXQg VExTdjQgb3IgZXF1aXZhbGVudCB3b3VsZCBiZSBhcHByb3ByaWF0ZS48L2Rpdj4NCjxkaXYgY2xh c3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPkF0IHRoaXMgcG9pbnQs IEnigJlkIHByZWZlciB0byBrZWVwIGl0IFRMU3YxLjMsIHNpbmNlIEkgZG9u4oCZdCBjb25zaWRl ciB0aGlzIGEgc2lnbmlmaWNhbnQgdXBkYXRlIHRvIHRoZSBwcm90b2NvbC48YnIgY2xhc3M9IiI+ DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgbGV0dGVy LXNwYWNpbmc6IG5vcm1hbDsgb3JwaGFuczogYXV0bzsgdGV4dC1hbGlnbjogc3RhcnQ7IHRleHQt aW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBub25lOyB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3 aWRvd3M6IGF1dG87IHdvcmQtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRo OiAwcHg7IHdvcmQtd3JhcDogYnJlYWstd29yZDsgLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOyAt d2Via2l0LWxpbmUtYnJlYWs6IGFmdGVyLXdoaXRlLXNwYWNlOyIgY2xhc3M9IiI+DQo8ZGl2IHN0 eWxlPSJjb2xvcjogcmdiKDAsIDAsIDApOyBsZXR0ZXItc3BhY2luZzogbm9ybWFsOyBvcnBoYW5z OiBhdXRvOyB0ZXh0LWFsaWduOiBzdGFydDsgdGV4dC1pbmRlbnQ6IDBweDsgdGV4dC10cmFuc2Zv cm06IG5vbmU7IHdoaXRlLXNwYWNlOiBub3JtYWw7IHdpZG93czogYXV0bzsgd29yZC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDsgd29yZC13cmFwOiBicmVhay13 b3JkOyAtd2Via2l0LW5ic3AtbW9kZTogc3BhY2U7IC13ZWJraXQtbGluZS1icmVhazogYWZ0ZXIt d2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+LS08L2Rpdj4NCjxkaXYgY2xh c3M9IiI+LVRvZGQgU2hvcnQ8L2Rpdj4NCjxkaXYgY2xhc3M9IiI+Ly8gPGEgaHJlZj0ibWFpbHRv OnRzaG9ydEBha2FtYWkuY29tIiBjbGFzcz0iIj50c2hvcnRAYWthbWFpLmNvbTwvYT48L2Rpdj4N CjxkaXYgY2xhc3M9IiI+Ly8gJnF1b3Q7T25lIGlmIGJ5IGxhbmQsIHR3byBpZiBieSBzZWEsIHRo cmVlIGlmIGJ5IHRoZSBJbnRlcm5ldC4mcXVvdDs8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rp dj4NCjxiciBjbGFzcz0iIj4NCjxkaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0i Ij4NCjxkaXYgY2xhc3M9IiI+T24gTm92IDIxLCAyMDE2LCBhdCAyOjUxIFBNLCBZb2F2IE5pciAm bHQ7PGEgaHJlZj0ibWFpbHRvOnluaXIuaWV0ZkBnbWFpbC5jb20iIGNsYXNzPSIiPnluaXIuaWV0 ZkBnbWFpbC5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJj aGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9 IiI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIiBjbGFzcz0iIj5PbiAyMSBOb3YgMjAxNiwgYXQg MjA6NDMsIFNhbHosIFJpY2ggJmx0OzxhIGhyZWY9Im1haWx0bzpyc2FsekBha2FtYWkuY29tIiBj bGFzcz0iIj5yc2FsekBha2FtYWkuY29tPC9hPiZndDsgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPGJy IGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xhc3M9 IiI+V2l0aCB0aGlzIGluIG1pbmQsIEknbSB2b3RpbmcgaW4gZmF2b3Igb2YgYW55IHJlLWJyYW5k aW5nIG9mIFRMUyAxLjMgd2hlcmUgdGhlPGJyIGNsYXNzPSIiPg0KcHJvdG9jb2wgbmFtZSByZW1h aW5zICZxdW90O1RMUyZxdW90OyBhbmQgbWFqb3IgdmVyc2lvbiBiZWNvbWVzICZndDsgMS48YnIg Y2xhc3M9IiI+DQo8L2Jsb2NrcXVvdGU+DQo8YnIgY2xhc3M9IiI+DQpNZSB0b28uPGJyIGNsYXNz PSIiPg0KPC9ibG9ja3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KQWdyZWU8YnIgY2xhc3M9IiI+DQo8 YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NClRMUyBtYWlsaW5nIGxpc3Q8YnIgY2xh c3M9IiI+DQo8YSBocmVmPSJtYWlsdG86VExTQGlldGYub3JnIiBjbGFzcz0iIj5UTFNAaWV0Zi5v cmc8L2E+PGJyIGNsYXNzPSIiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by90bHM8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_A101A351B70A49A095A03DEE467325F5akamaicom_-- From nobody Mon Nov 21 12:13:35 2016 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 97B2D12007C for ; Mon, 21 Nov 2016 12:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 yL19IU9Emwku for ; Mon, 21 Nov 2016 12:13:33 -0800 (PST) Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BCB6127076 for ; Mon, 21 Nov 2016 12:13:33 -0800 (PST) Received: from [192.168.123.7] (unknown [76.90.60.238]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 3ACAC22E25B for ; Mon, 21 Nov 2016 15:13:26 -0500 (EST) To: tls@ietf.org References: From: Sean Leonard Message-ID: <4df6cd5a-04de-841b-817c-e9090803c076@seantek.com> Date: Mon, 21 Nov 2016 12:13:35 -0800 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 20:13:35 -0000 +1 to TLS 1.3. My strong preference is TLS 1.3. Reasons have been advanced ad-nauseam. Just a couple of additional thoughts: 1.3 is in the protocol. So there. "Perl 6". Just because you advance a version number to a big one,=20 doesn't mean that businesses will see the justification to upgrade. Sean On 11/17/2016 6:12 PM, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG shou= ld rebrand TLS1.3 to something else. Slides can be found @ https://www.i= etf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to n= ot rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decis= ion on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. > > Thanks, > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Mon Nov 21 12:13:50 2016 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 6F81512948C for ; Mon, 21 Nov 2016 12:13:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ipv-sx.20150623.gappssmtp.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 PfD6s24v1jv0 for ; Mon, 21 Nov 2016 12:13:47 -0800 (PST) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 5A90F12945F for ; Mon, 21 Nov 2016 12:13:47 -0800 (PST) Received: by mail-ua0-x236.google.com with SMTP id b35so236086686uaa.3 for ; Mon, 21 Nov 2016 12:13:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipv-sx.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=uf7sam8v8k8S77NcevE7zaUnTewuJWIBG/goJdz5hCI=; b=AMEmp1IzF4oLUCLBV/Zzdayq2fp4yEhAXBa25c3dRempcFQVUaGsV0giZZfp1u5+Kl W5haJXpP2nzbJybJdTCIUQYB8RcgqShfezfiPCJ0T7wi+qeaYCk8xFfCER8lKjFZoWPg N/1vno05Eu/BZG0B8/6Ff8L6VLn9yjkOQw5rvRXc+YLRmyIBb4GQlaslYmEILB7ZeTrA TsfREAwZLQKKZ36tZbOrFP/RKoxJYRBIgMnJFA0Q8iUe4fkcmxVsm5rEMh/x9OncDdrb 5EwhS2R8yza0tR0w01zrgOPGA/cYimtfv979tNbb2MV16/fRTd6jI+anraA44Gqq4Wkd SPkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uf7sam8v8k8S77NcevE7zaUnTewuJWIBG/goJdz5hCI=; b=kwcN8MSj39/xHs0tlzNtHFSzm0sz0FAhkXkZmzlzTvrHJOuITYQGJ8ZdBT1Isd1RFl e5RYCQOfV4YRVZIEwXpHSg/MwMp5nT/ae9hhdWWXVkCyTNWWRZLCB1u/Fel2DN4ckqft YpG/LYxUUxbAlmpSPuv5EcsE1WcVn03w4043UsV6mMr1JHsB8F+VenC7VdRrY2Dy0w3n d20aLnKCMW9EU4u3jlRydZKn7a5rGAT0GUfKyIClzGCUGq1ICBbDknpidNBkLtUcYTED GmtPAS1wVq1dEk3ODZbzi9cKL6arspgNZfcjYLHwO3MAxzSusM490pJ+2pObaOA6RnoM LbpA== X-Gm-Message-State: AKaTC02RzJFkt+5JvZs2fU933VuZJr6Jtz/Rn039hEK5iDMPeoUpTP0jArqRrpij58wktUoJVAHOY5fa5XTg0Q== X-Received: by 10.176.5.137 with SMTP id e9mr6609286uae.109.1479759226430; Mon, 21 Nov 2016 12:13:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.31.41.17 with HTTP; Mon, 21 Nov 2016 12:13:44 -0800 (PST) In-Reply-To: References: <20161118121909.GA28464@LK-Perkele-V2.elisa-laajakaista.fi> <1479474222033.25911@cs.auckland.ac.nz> <20161118154043.GA28666@LK-Perkele-V2.elisa-laajakaista.fi> <1479523253827.80996@cs.auckland.ac.nz> From: Richard Barnes Date: Mon, 21 Nov 2016 15:13:44 -0500 Message-ID: To: Yoav Nir Content-Type: multipart/alternative; boundary=94eb2c1232180b7e800541d54b28 Archived-At: Cc: "" Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 20:13:49 -0000 --94eb2c1232180b7e800541d54b28 Content-Type: text/plain; charset=UTF-8 On Mon, Nov 21, 2016 at 2:51 PM, Yoav Nir wrote: > > > On 21 Nov 2016, at 20:43, Salz, Rich wrote: > > > > > >> With this in mind, I'm voting in favor of any re-branding of TLS 1.3 > where the > >> protocol name remains "TLS" and major version becomes > 1. > > > > Me too. > > Agree > I can live with this approach, though if we go this way, I would have a strong preference for 4, as the minimum change that gets us clear of the SSL version numbers. That said, I still think 1.3 is the most sensible option. Regardless of what we do here, we're still going to have to struggle with "N > 1.2 > 1.1 > 1.0 > 3.0" for a long time. The only decision we've got here is which additional exasperating conversation we want to have in the future, "Yes, N is the one that comes after 1.2", or "Yes, 1.3 > 3.0". Might as well stick with the one we've been having all along anyway. --Richard > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1232180b7e800541d54b28 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 21, 2016 at 2:51 PM, Yoav Nir <ynir.ietf@gmail.com&g= t; wrote:

> On 21 Nov 2016, at 20:43, Salz, Rich <rsalz@akamai.com> wrote:
>
>
>> With this in mind, I'm voting in favor of any re-branding of T= LS 1.3 where the
>> protocol name remains "TLS" and major version becomes &g= t; 1.
>
> Me too.

Agree

I can live with this appro= ach, though if we go this way, I would have a strong preference for 4, as t= he minimum change that gets us clear of the SSL version numbers.

That said, I still think 1.3 is the most sensible option.=C2=A0 Reg= ardless of what we do here, we're still going to have to struggle with = "N > 1.2 > 1.1 > 1.0 > 3.0" for a long time.=C2=A0 Th= e only decision we've got here is which additional exasperating convers= ation we want to have in the future, "Yes, N is the one that comes aft= er 1.2", or "Yes, 1.3 > 3.0".=C2=A0 Might as well stick w= ith the one we've been having all along anyway.

--Richard


=C2=A0


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c1232180b7e800541d54b28-- From BATV+8997188884ea56d331b4+4838+infradead.org+dwmw2@bombadil.srs.infradead.org Mon Nov 21 12:20:22 2016 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 7608B129B90 for ; Mon, 21 Nov 2016 12:20:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 rnKfOEJQgvPe for ; Mon, 21 Nov 2016 12:20:21 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org [IPv6:2001:1868:205::9]) (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 2EBAC129518 for ; Mon, 21 Nov 2016 12:20:21 -0800 (PST) Received: from [2001:8b0:10b:1:841b:5eff:0:3b3] (helo=i7.infradead.org) by bombadil.infradead.org with esmtpsa (Exim 4.85_2 #1 (Red Hat Linux)) id 1c8v4d-0004rp-Jh; Mon, 21 Nov 2016 20:20:19 +0000 Message-ID: <1479759617.8937.13.camel@infradead.org> From: David Woodhouse To: "Salz, Rich" , =JeffH , IETF TLS WG Date: Mon, 21 Nov 2016 20:20:17 +0000 In-Reply-To: <66622e93160d4670b4a425b2c93ea27c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2f776cf5-45b7-a382-28c4-2cd066336e0d@KingsMountain.com> <66622e93160d4670b4a425b2c93ea27c@usma1ex-dag1mb1.msg.corp.akamai.com> Content-Type: multipart/signed; micalg="sha-256"; protocol="application/x-pkcs7-signature"; boundary="=-1K20g7VXT9yGJMEiflAC" X-Mailer: Evolution 3.22.1 (3.22.1-2.fc25) Mime-Version: 1.0 X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 20:21:19 -0000 --=-1K20g7VXT9yGJMEiflAC Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, 2016-11-21 at 19:34 +0000, Salz, Rich wrote: > Do "about:config" in firefox and look for TLS: > security.tls.version.max default integer 3 >=20 > And then perhaps look at http://kb.mozillazine.org/Security.tls.version.*= (yes the star is part of the URL) >=20 > EVEN MOZILLA can't get it "right." What's wrong with that? On a version of Firefox which supports only up to TLSv1.2, the default setting of=C2=A0security.tls.version.max is 3 (i.e. TLSv1.2). Which seems reasonable enough. If you update to a hypothetical newer version of Firefox+NSS which supports a newer version of TLS, presumably the default value of security.tls.version.max will be 4, and will take effect unless you've manually set it to any other value in your own local config. --=20 dwmw2 --=-1K20g7VXT9yGJMEiflAC Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCCEeAw ggXiMIIDyqADAgECAhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYT AklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0 aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTAeFw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0 eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17AkefMyUGwrQdvwO bhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzLA84J6Ws5T4NfXZ0q n4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmCS+kICslYYWgXOMt2xlsS slxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6mySu8j8BWWHpChNNeTrFuhVfrO AyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR9t4APXGzAgMBAAGjggFkMIIBYDAO BgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQI MAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2Eu Y3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDAGCCsGAQUFBzAChiRodHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0O BBYEFCSBbDlhvkkPj7cbRivJKLUnSG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7y MD8GA1UdIAQ4MDYwNAYEVR0gADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNv bS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh 2NCXTq7im61g7F1LIiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw 5kG3DN8pd1hSEUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07 v29MdhaPv3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Y klue/quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6UpVD o/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHMzcwk3EV2 B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuKKwHNL8F4GGp6 jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ8j6y6S9p0xE/Ga0p eVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByve JDANBgkqhkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEp MCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0 Q29tIENsYXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEc MBoGA1UEAwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFk ZWFkLm9yZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4z x6Yt3dOUI5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+ tN/GUsyws26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4m liy6WRDKApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO 2mDA8KZ4h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8f wSR3tYeW9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7t w68Ugk0MMfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTAR Q+k8lbpkx2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BK FSb7x5M1KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQU IIWlyRsm2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNV HQ8BAf8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYD VR0OBBYEFBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUn SG1oMG8GCCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29t MDkGCCsGAQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5j cnQwOAYDVR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEu Y3JsMB4GA1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYe aHR0cDovL3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0V kS226sFKAbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZL cSsbpW3AYPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqo WragTXfsIXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8 edaRzkYhzxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFuc CWpS8hxjTmYcNZSibv+3Oy6uU+wqMIIF+TCCBOGgAwIBAgIQaRjuleoVgt0XsPAUByveJDANBgkq hkiG9w0BAQsFADB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UE CxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENs YXNzIDEgQ2xpZW50IENBMB4XDTE2MDMxMjE2MjEyNVoXDTE3MDMxMjE2MjEyNVowQjEcMBoGA1UE AwwTZHdtdzJAaW5mcmFkZWFkLm9yZzEiMCAGCSqGSIb3DQEJARYTZHdtdzJAaW5mcmFkZWFkLm9y ZzCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoCggIBANBDAiGnoeOIQJ/Aolutct4zx6Yt3dOU I5d0YnydAMNOiyVLXzHuuuVjUpk/6nRxg1FN3e0i3TWe5MjSTD98760qWoAuF2g5BGU+tN/GUsyw s26ZWOt82w7xhn4dcI8EhmASUtwDTZs5ZXPQzSkuNs6uX5SY0eKPlBNHkAtMf39hNc4mliy6WRDK ApZxA1vCbiHsJQZdNEBYO35022bu8PZBe6LSAFKoncoGMHl1xNEkN6kfOJFYnLqBYeXO2mDA8KZ4 h15EnQyyHGSghN92OUTc9stAWEt9a+q6TCtyW5zNgYTaaOtE41t5x2xDAgsnNU7sVM8fwSR3tYeW 9IqTgU6eDUllb1a9FK7es3+j9UDg7OxNv9rnXIda6TdXlGWYfFltujF7FMwTofq3UG7tw68Ugk0M MfpZadhPhjYLI/qXiEDgQi8Xr+eWSo5P0ygaLvAz8OPcWAt8RG5Y8Id9hpb5neW1HTARQ+k8lbpk x2wDPHZEft0ITROOupf76f9CNF4jYcyCKZNnjSsKeJv69VX1TsVaeqT1LJUEudXLa/BKFSb7x5M1 KF4z46yImJrnagI19Nk/ufWn1usBXqXh8pY8cVN/I7C+TDPBY5SqIceTq7DaHZp19JQUIIWlyRsm 2d4UoVcgIdTjX57Odap4Pjzrfp2RmC6hvkW2hQ5EreIPAgMBAAGjggG2MIIBsjAOBgNVHQ8BAf8E BAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYE FBDmK2IjZJ7MKmBK0A7J/tKaSIdoMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8G CCsGAQUFBwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsG AQUFBzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3JsMB4G A1UdEQQXMBWBE2R3bXcyQGluZnJhZGVhZC5vcmcwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vMEYGA1UdIAQ/MD0wOwYLKwYBBAGBtTcBAgQwLDAqBggrBgEFBQcCARYeaHR0cDov L3d3dy5zdGFydHNzbC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4IBAQAn5wvdgC0VkS226sFK AbqPnmVhc9jgrbsiXUcpdtYEzv6EZonARIeRC1UlIzK7jzZFRe95W5y4/qlcPQDoAeZLcSsbpW3A YPFFWdRgVp/eIR3iy9C5KEcAbkJES2lRUZWyRqAceW1Gur9kfvjM5H0kM6BBwJfCtoqoWragTXfs IXGNsF0F+60mUYYsKFPZzPmyz9J0Dr0xx9Lcp4fbD6UckDWCNJt2AJAiEPt/vPiiBzU8edaRzkYh zxd9f3pZAzhlzIf2CgTrGtKSL2X1bS/b3siREjQLhVrlGw4qxqllqER3APrDzyijLFucCWpS8hxj TmYcNZSibv+3Oy6uU+wqMYIEXjCCBFoCAQEwgYkwdTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0 YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMw IQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENsaWVudCBDQQIQaRjuleoVgt0XsPAUByveJDANBglg hkgBZQMEAgEFAKCCAaUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcN MTYxMTIxMjAyMDE3WjAvBgkqhkiG9w0BCQQxIgQgGxYnvySM4kbfYTX4HSj5im9GE3Oaky89w1gh OaKweC4wgZoGCSsGAQQBgjcQBDGBjDCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNV BAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMIGcBgsqhkiG 9w0BCRACCzGBjKCBiTB1MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcG A1UECxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29t IENsYXNzIDEgQ2xpZW50IENBAhBpGO6V6hWC3Rew8BQHK94kMA0GCSqGSIb3DQEBAQUABIICAFG0 PLac82ASuYxZ/m3VWFd4UzrtMOug64AyxzlI49Odm5xhcgNzM/xIFazcjOAeMH9UAxDOOXVsckYy JJYlx5RntgmoDhuR2QvV6cJTjWd3SQf5uEVxIzZ9isvrr9/hlDGkJwN0+GEruMZTF9rdsYJZVtfn HF2xHRsvQwaOMZKVch6TZCvrocNJ4mpx0rtCMG5ak6RbFQDAqe545fCw/r7gbpHT++lkd6ySC6Tz z5j9y1Aiq6hb48QSS0QnIMAz+PP7Ba5ZBYEFynPsimkD8VDxabErU3xe3/WxyOhwCZpB2IXnxqsn LFGgQyTbwqPe0lVKY76sBJX8G5zZDKMXfYK/jLLJ+QqN7Xb9yQHutOaYMlHySSd958cyenYCz8RA 5Wzj1PQ83B1E021mTefMjKqqpo57MqhfmxK93R5DmlRD99iOZYIGZ2GKgMXabTagtj1QRr+41c2K yn9j14lD7qp2VpeeYVgQhHLPYVr5sQVTc84ilinzL4YgikJ+Z0bTYygAMgtM8u6/1FyLdl2wZB5f dVVhn3ectBQY3/pj/cw6xS9jKc3SACaKHkUJ3IuyQpHJQ4IoqIm1kCFczQb/4upeRq6mYnCvQZAn j53WQWHznG3ftPmS07cumoMy5rrQMQ/YfrBDFJRlqsjbDlVG/cr6uBdIGHyiR/JHj/qLG+3DAAAA AAAA --=-1K20g7VXT9yGJMEiflAC-- From nobody Mon Nov 21 12:33:13 2016 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 75A8E1294FA for ; Mon, 21 Nov 2016 12:33:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 bzUys9nB6RVJ for ; Mon, 21 Nov 2016 12:33:11 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2E20D12943C for ; Mon, 21 Nov 2016 12:33:11 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9C24E433401; Mon, 21 Nov 2016 20:33:10 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 833F7433404; Mon, 21 Nov 2016 20:33:10 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1479760390; bh=OrZsbNky/nGxGqqKpr181eKMfNfHvHCI++dge2AUM7M=; l=522; h=From:To:CC:Date:References:In-Reply-To:From; b=FBQOEtFmVI9hmUaa0/azI7zGuy2j/mx83WXV10VB7q8eLWtZ3Z+F8J1D0T4FGN2nF nhqGrSnS8nhXTukh/fznnCgIq1emlkbwAoKh0RwJUtLbhfTg2pej9IXSGzj+In5nHC How2Rb8ywBQ/Q4g+oYgvCfQI0J8yr4WeKixBaL0E= Received: from email.msg.corp.akamai.com (ecp.msg.corp.akamai.com [172.27.123.34]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id 785151FC90; Mon, 21 Nov 2016 20:33:10 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Mon, 21 Nov 2016 15:33:10 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Mon, 21 Nov 2016 15:33:10 -0500 From: "Salz, Rich" To: Eric Rescorla Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSRCt9yvv3al+6E0mEp3NhmRhrEqDj0xVQgABcJAD//7UewA== Date: Mon, 21 Nov 2016 20:33:10 +0000 Message-ID: <13d9c4c978144b93b940d2a3759a529f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2f776cf5-45b7-a382-28c4-2cd066336e0d@KingsMountain.com> <66622e93160d4670b4a425b2c93ea27c@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.39.115] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: IETF TLS WG Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 20:33:12 -0000 4p6iIFlvdSBzaG91bGQgYmUgcmVsdWN0YW50IHRvIGRyYXcgdG9vIG1hbnkgY29uY2x1c2lvbnMg ZnJvbSBhIGZpZWxkIHdoaWNoIHlvdSBjYW4gb25seSBhY2Nlc3MgYnkgY2xpY2tpbmcgdGhyb3Vn aCBhIGJpZyBzY2FyeSB3YXJuaW5nIHRoYXQgeW91IGFyZSB2b2lkaW5nIHlvdXIgd2FycmFudHk6 DQoNCldhcnJhbnR5Pw0KDQpBbmQgc3VyZSwgdXNlcnMgbmV2ZXIgY2xpY2sgdGhyb3VnaCBzZWN1 cml0eSB3YXJuaW5ncyDimLoNCg0KQXQgYW55IHJhdGUsIHRoaXMgd2FzIGludGVuZGVkIHRvIGJl IGEgbGl0dGxlIGxpZ2h0LWhlYXJ0ZWQsIGJ1dCBtaWdodCBoYXZlIHJ1YmJlZCBzb21lIGZvbGtz IHRoZSB3cm9uZyB3YXkuICBTb3JyeSDigJhib3V0IHRoYXQuDQo= From nobody Mon Nov 21 12:42:46 2016 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 0EB6F129BA1; Mon, 21 Nov 2016 12:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 oOY9D_2gHFtO; Mon, 21 Nov 2016 12:42:39 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id D8A9B129BA2; Mon, 21 Nov 2016 12:42:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id A7A2413AA7; Mon, 21 Nov 2016 22:42:37 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id GtxDQNHMU70p; Mon, 21 Nov 2016 22:42:37 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4D96D283; Mon, 21 Nov 2016 22:42:37 +0200 (EET) Date: Mon, 21 Nov 2016 22:42:31 +0200 From: Ilari Liusvaara To: "Dang, Quynh (Fed)" Message-ID: <20161121204231.GA9484@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "cfrg@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 20:42:41 -0000 On Mon, Nov 14, 2016 at 02:54:23AM +0000, Dang, Quynh (Fed) wrote: > > Rekeying too often than needed would just create more room for > issues for the connection/session without gaining any additional > practical security at all. With regards to rekeying frequency I'm concerned about testability, have it to be too rare and it is pretty much as good as nonexistent. This is the reason why I set the rekey limit to 2M(!) records in btls (with first rekey at 1k(!) records). These limits have absolutely nothing to do with any sort of cryptographic reasoning[1][2]. [1] If they did, then Chacha rekey limit would be when RSN exhaustion is imminent (since RSNs can't wrap, but can be reset). [2] The 2M limit is chosen so that it is reached in ~1minute in fast transfer tests. -Ilari From nobody Mon Nov 21 14:40:14 2016 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 377BE1295FC for ; Mon, 21 Nov 2016 14:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 pOvzCjNszUle for ; Mon, 21 Nov 2016 14:40:11 -0800 (PST) Received: from mail-yw0-x241.google.com (mail-yw0-x241.google.com [IPv6:2607:f8b0:4002:c05::241]) (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 AF3CD1293E4 for ; Mon, 21 Nov 2016 14:40:11 -0800 (PST) Received: by mail-yw0-x241.google.com with SMTP id b66so6689ywh.2 for ; Mon, 21 Nov 2016 14:40:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:cc; bh=0w0G0qr50utqD4Ff5bdmFJC3aHFQUuc0sbR5JXODis8=; b=HBj0a6TNU2MsvqTRiOsQpu2GdYC+8OS2C+jbJM9Ey/PuMAwsywPQDRA8AchThDFJzr Hg2kflPjl/5DSNoImiBN6LDUmrDyJHjI8XnyoXdoU6KuvbqjSxC43zbiDCuAD4T2dGgX 889Lp/YEk40sC5UK4xXBok217t+LxNyXSZbB75to0wizcC3kImjsuzRgeFu1H3rSf7qN 4yBba//prAlKPHq0GC2wBrR+v6ZB9EUJOMhXEDsSF8uyZMFWeLOw5VyFSODTdRtmXrVW +KLvaEutd7AG3yUy1vcl65oCVn+sy0o+60+IhcGmeF2ObH3pV1NAn3IE0ju0fjMaHFbr 57KQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:cc; bh=0w0G0qr50utqD4Ff5bdmFJC3aHFQUuc0sbR5JXODis8=; b=ZvAGEqJ9V/DjklX5ZiWU1oC5PWhiIbnLqmyIFmPcBkXcY7+bXGYEewsBbskcFBpn2B dYzW9Q95bR+43n3hiU+h6FZXMDv2ejGshcQmKqMI8Q4JtKJA5Gv5d2SJm2+HQ2zP+r+g Mrt/JZdeWub3Vc01oIqNMj72bxvQGlb8QqHr9OLHxwvTSS/XzhXWInCgOjaGkQrbtoMD mYmVx/vIwF38SrOa9kC+TBcc3qN1zNtQARppCR7p87HRQ6jU2LikgRxUk8Iov1mL07O6 yrcMpnIK3pXV2Y0l9579Fwn9FNHVmSZEvSBhICqNuXrjkJ4Co8Zf+y/Xi3TzOI9ptX4D rY5Q== X-Gm-Message-State: AKaTC03Qexy+xYJVHUwJh09jB0emc2f0oqXSa5uYEr8MDg+BbWZo+iZDWWAKO0h/42Mdr8HIOXGsJe4LbIM0Tg== X-Received: by 10.129.102.132 with SMTP id a126mr16558188ywc.160.1479768010759; Mon, 21 Nov 2016 14:40:10 -0800 (PST) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.37.170.112 with HTTP; Mon, 21 Nov 2016 14:39:39 -0800 (PST) In-Reply-To: <13d9c4c978144b93b940d2a3759a529f@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2f776cf5-45b7-a382-28c4-2cd066336e0d@KingsMountain.com> <66622e93160d4670b4a425b2c93ea27c@usma1ex-dag1mb1.msg.corp.akamai.com> <13d9c4c978144b93b940d2a3759a529f@usma1ex-dag1mb1.msg.corp.akamai.com> From: Hugo Krawczyk Date: Mon, 21 Nov 2016 17:39:39 -0500 X-Google-Sender-Auth: HG2Ts-fyu--PRSacql5wwxfVXnE Message-ID: Cc: IETF TLS WG Content-Type: multipart/alternative; boundary=001a114901b6a1a2770541d75653 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 22:40:14 -0000 --001a114901b6a1a2770541d75653 Content-Type: text/plain; charset=UTF-8 If it wasn't because we don't need more noise in this discussion I would have suggested SSL 5.0 which seems to be the logical conclusion from the reasoning people are using. Clearly, everyone thinks that the battle of replacing "SSL" with "TLS" in the popular and technical references to the standard has been lost and there is not much hope to win it in the future. So if the mountain won't come to Muhammad then go back to SSL and call it SSL 5.0 leaving SSL 4.0 as an historic parallel/re-naming of TLS 1.0. (Also note that the two 'S' of SSL already hint to the number 5 and L is 50 in Roman numerals.) On a more serious note, I would keep a minor option in whatever is chosen (e.g. 4.0). The reason is that I can see more resistance in the future to minor revisions if such revision needs to be called TLS 5 rather than 4.1. However, minor but crucial revisions may be needed sooner than one hopes for and delaying them for when more changes are accumulated is not a good thing. Hugo --001a114901b6a1a2770541d75653 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
If it wasn't because we don't need more= noise in this discussion I would have suggested SSL 5.0 which seems to be = the logical conclusion from the reasoning people are using. Clearly, everyo= ne thinks that the battle of replacing "SSL" with "TLS"= in the popular and technical references to the standard has been lost and = there is not much hope to win it in the future.
So if the m= ountain won't come to =C2=A0Muhammad then go back to SSL and call it SS= L 5.0 leaving SSL 4.0 as an historic parallel/re-naming of TLS 1.0. (Also n= ote that the two 'S' of SSL already hint to the number 5 and L is 5= 0 in Roman numerals.)

On a more seriou= s note, I would keep a minor option in whatever is chosen (e.g. 4.0). The r= eason is that I can see more resistance in the future to minor revisions if= such revision needs to be called TLS 5 rather than 4.1. However, minor but= crucial revisions may be needed sooner than one hopes for and delaying the= m for when more changes are accumulated is not a good thing.

Hugo

--001a114901b6a1a2770541d75653-- From nobody Mon Nov 21 15:02:05 2016 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 5DB321293E4; Mon, 21 Nov 2016 15:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nistgov.onmicrosoft.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 V5glUs3d1KdA; Mon, 21 Nov 2016 15:02:01 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0094.outbound.protection.outlook.com [23.103.200.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE8F1294E8; Mon, 21 Nov 2016 15:02:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=OTwhLGIm7WCd355VH/CQ4y8u1vCFrAU1uH44r4psE/s=; b=LT8cf8HE7hYg80DFhOIj3hWFTuY/NZDzAXOq8PyAxGiX+kD5MZ6mNar5DMsZsRQ+LniADfSrkPD+IQIUfaIa3m2Y6d/PmNVHUSIXvJ3ZsfQvUCFhHl+HzLzwVtKj7cBUaxdESw3uBavsbGzOOl3JSwBVeBoCTSrZ5OWSeN5i2Xc= Received: from CY4PR09MB1464.namprd09.prod.outlook.com (10.173.191.22) by CY4PR09MB1461.namprd09.prod.outlook.com (10.173.191.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.734.8; Mon, 21 Nov 2016 23:01:59 +0000 Received: from CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) by CY4PR09MB1464.namprd09.prod.outlook.com ([10.173.191.22]) with mapi id 15.01.0734.013; Mon, 21 Nov 2016 23:01:59 +0000 From: "Dang, Quynh (Fed)" To: Ilari Liusvaara Thread-Topic: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5 Thread-Index: AQHSPe67hB6sb8v2EES9vmvjfbAsXqDXlqSAgAAv0JWADC09gIAAJjCn Date: Mon, 21 Nov 2016 23:01:59 +0000 Message-ID: References: , <20161121204231.GA9484@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20161121204231.GA9484@LK-Perkele-V2.elisa-laajakaista.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=quynh.dang@nist.gov; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [129.6.222.56] x-microsoft-exchange-diagnostics: 1; CY4PR09MB1461; 7:Ng8lLxIH7x/ixDqjUj6mzoZ3u1FYGEax+p7ZwERoIf6KZwIv67CGbLF6+mNqkVqyBMXGdUBW9iD18G1G9CDPVbgVzv28B2hHcpp8XQg3B4gRHqFjTOxjvVqcTuM128l0Y/ej+OKfFzlp+L1AVQ59X1nTtGcn1lJW7otbNDxU6ciYYpTFannBtHjonHf+U0bmXkGPrk+WRAiFitInhfvN8zHWjeeB4ng+4Cih+hXWzYFIqLS17H6bKeYuCG9QoUt6IcCRP8L+VSXarkp8kN8NG9ng1r/k85VqhmyTZ7rzVGToINnMgp5n4huUVlhsv8sZpMA8oCE3Wf8P7oExvpJl/YdElPIa4a87DF6QNrsOc/8= x-ms-office365-filtering-correlation-id: 7caf4f19-b88a-4e69-683f-08d412626611 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR09MB1461; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040307)(6060326)(6045199)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(6061324)(6072148)(6042181); SRVR:CY4PR09MB1461; BCL:0; PCL:0; RULEID:; SRVR:CY4PR09MB1461; x-forefront-prvs: 01334458E5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(377454003)(199003)(189002)(189998001)(5660300001)(7696004)(229853002)(66066001)(92566002)(54356999)(50986999)(76176999)(101416001)(33656002)(76576001)(3660700001)(3280700002)(2906002)(87936001)(9686002)(106356001)(4326007)(6606003)(7736002)(2950100002)(8936002)(74316002)(7846002)(106116001)(97736004)(6916009)(77096005)(105586002)(68736007)(8676002)(122556002)(99286002)(81156014)(110136003)(19627405001)(6116002)(2900100001)(86362001)(93886004)(102836003)(6506003)(3846002)(38730400001)(81166006); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR09MB1461; H:CY4PR09MB1464.namprd09.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nist.gov does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_CY4PR09MB14646C5559950CDF77AA665AF3B50CY4PR09MB1464namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2016 23:01:59.3533 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR09MB1461 Archived-At: Cc: "cfrg@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 21 Nov 2016 23:02:04 -0000 --_000_CY4PR09MB14646C5559950CDF77AA665AF3B50CY4PR09MB1464namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ilari, You were right, for testing, a smaller number should be used. Quynh. ________________________________ From: ilariliusvaara@welho.com on behalf of Ilar= i Liusvaara Sent: Monday, November 21, 2016 3:42 PM To: Dang, Quynh (Fed) Cc: Martin Thomson; tls@ietf.org; cfrg@ietf.org Subject: Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for cip= hertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5 On Mon, Nov 14, 2016 at 02:54:23AM +0000, Dang, Quynh (Fed) wrote: > > Rekeying too often than needed would just create more room for > issues for the connection/session without gaining any additional > practical security at all. With regards to rekeying frequency I'm concerned about testability, have it to be too rare and it is pretty much as good as nonexistent. This is the reason why I set the rekey limit to 2M(!) records in btls (with first rekey at 1k(!) records). These limits have absolutely nothing to do with any sort of cryptographic reasoning[1][2]. [1] If they did, then Chacha rekey limit would be when RSN exhaustion is imminent (since RSNs can't wrap, but can be reset). [2] The 2M limit is chosen so that it is reached in ~1minute in fast transfer tests. -Ilari --_000_CY4PR09MB14646C5559950CDF77AA665AF3B50CY4PR09MB1464namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Ilari,


You were right, for testing, a smaller number should be used. 


Quynh. 





From: ilariliusvaara@welh= o.com <ilariliusvaara@welho.com> on behalf of Ilari Liusvaara <ila= riliusvaara@welho.com>
Sent: Monday, November 21, 2016 3:42 PM
To: Dang, Quynh (Fed)
Cc: Martin Thomson; tls@ietf.org; cfrg@ietf.org
Subject: Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability = for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5
 
On Mon, Nov 14, 2016 at 02:54:23AM +0000, Dang= , Quynh (Fed) wrote:
>
> Rekeying too often than needed would just create more room for
> issues for the connection/session without gaining any additional
> practical security at all.

With regards to rekeying frequency I'm concerned about testability,
have it to be too rare and it is pretty much as good as nonexistent.

This is the reason why I set the rekey limit to 2M(!) records in
btls (with first rekey at 1k(!) records). These limits have absolutely
nothing to do with any sort of cryptographic reasoning[1][2].




[1] If they did, then Chacha rekey limit would be when RSN exhaustion
is imminent (since RSNs can't wrap, but can be reset).

[2] The 2M limit is chosen so that it is reached in ~1minute in fast
transfer tests.


-Ilari
--_000_CY4PR09MB14646C5559950CDF77AA665AF3B50CY4PR09MB1464namp_-- From nobody Tue Nov 22 07:05:10 2016 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 4991D12966C for ; Tue, 22 Nov 2016 07:05:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 mG0ulH9NjKwD for ; Tue, 22 Nov 2016 07:05:04 -0800 (PST) Received: from resqmta-po-01v.sys.comcast.net (resqmta-po-01v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:160]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF914129565 for ; Tue, 22 Nov 2016 07:05:01 -0800 (PST) Received: from resomta-po-03v.sys.comcast.net ([96.114.154.227]) by resqmta-po-01v.sys.comcast.net with SMTP id 9CcicIXzBucHZ9Cd2cXCg4; Tue, 22 Nov 2016 15:05:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1479827100; bh=MOCROJa9Yc/6pIhysPnuAEwR8Psk8m/gac0mVYVsPYI=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=RiqM1JWBCafDPckW1QwCQs5L3SAQodSp4KhQkMI1MtLDRHvZzJ+DSZKzALLK8w2Bb 3oj3EswIvvaohR4b0QOwfyk8wlhrKQ3UZXzzSWTV7W1q2S/lFbh9d4gLT+et+V4Yi2 cdg4cOXEvVGLoOU235Ae2XNHFD7OgD4rttSVY2KjMfSIxbNyNPxc8kGYhh+JHK6QP0 9pt7aBLZA1WN4AxZnvd5siqs5qGywS2Xjsv8yxisaz+NxUWw/gyzz0Hd535VdhOKIG TZPepNxFWQIDAlThvwl7YzVnH2110uEYL7iwkPY70gR4F5sDogbUUiQ+/KQ10ovREV OeekNHmxt95vg== Received: from odin.ULTHAR.us ([IPv6:2001:470:8c86:0:225:64ff:fe8b:c2f2]) by resomta-po-03v.sys.comcast.net with SMTP id 9CcrcNyGD1Uzn9CcwcXleH; Tue, 22 Nov 2016 15:04:58 +0000 Received: from odin.ULTHAR.us (localhost [127.0.0.1]) by odin.ULTHAR.us (8.15.2/8.14.5) with ESMTP id uAMF4mpU002837 for ; Tue, 22 Nov 2016 10:04:48 -0500 Received: (from draco@localhost) by odin.ULTHAR.us (8.15.2/8.15.2/Submit) id uAMF4m0P002836 for tls@ietf.org; Tue, 22 Nov 2016 10:04:48 -0500 Date: Tue, 22 Nov 2016 10:04:48 -0500 From: Scott Schmit To: tls@ietf.org Message-ID: <20161122150447.GA21794@odin.ULTHAR.us> References: MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha-256; boundary="+HP7ph2BbKc20aGI" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) X-CMAE-Envelope: MS4wfLpGfw7XGE9Lle6KhIOf1ACHtGJWFzuE7r0CbxZj1sJcGaUsHd0w/GHr1J+P4ADiV6qyNYN+l2XnazSDr8w3xO5LO2r1gfQ8uDy4KXPKf5Aby25wlADz KupcecQtecKwTxqO0KFdN/51n5ouG2K8PJ0= Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 15:05:08 -0000 --+HP7ph2BbKc20aGI Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should= rebrand TLS1.3 to something else. Slides can be found @ https://www.ietf.= org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. >=20 > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not= rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision = on the list so please let the list know your top choice between: >=20 > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 >=20 > by 2 December 2016. I find it compelling that if we lived in an alternate universe where we had SSL 1996, TLS 1999, and a recently-published TLS 2006 or TLS 2008, there would have been a lot less inertia about switching to a later version. I find is very optimistic given our history that we could manage two TLS versions in a year. If that ever happened, though, we could do 2019.1 (as an increment) or 2019.11 (for the month). Barring that, I'd prefer TLS 4, since that gets us out of the version confusion swamp. It would seem that almost nobody outside the security community understands the distinction between SSL and TLS; so if we call it TLS 4, we'll probably see it referred to as SSLv4. And that wouldn't be horrible. If we call it TLS 2 or TLS 2.0, some might refer to it as SSLv2. That would obviously be very bad. While it's nice to able to look up information about TLS 1.3 drafts, most of that information is going to be inaccurate anyway, so I don't see that as a compelling reason to stick to it. Granted, you have specific buzz for "TLS 1.3 is going to really improve things" but that's fairly easy to translate to "the new version of TLS is going to really improve things". The distinction between 2 vs 2.0 seems pretty minor. SSLv2 is 2.0 and SSLv3 is 3.0, but few write it that way. Thus my ranked preference would be: TLS 2017 > TLS 4 > TLS 1.3 > TLS 2 or TLS 2.0 But if I'm limited to a top choice from the list, then "Rebrand TLS 4" --=20 Scott Schmit --+HP7ph2BbKc20aGI Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIINuQYJKoZIhvcNAQcCoIINqjCCDaYCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggrhMIIF4jCCA8qgAwIBAgIQa6eKfQrXiNZRCvlZ5Oe04TANBgkqhkiG9w0BAQsFADB9 MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJl IERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UEAxMgU3RhcnRDb20gQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkwHhcNMTUxMjE2MDEwMDA1WhcNMzAxMjE2MDEwMDA1WjB1MQsw CQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEpMCcGA1UECxMgU3RhcnRDb20g Q2VydGlmaWNhdGlvbiBBdXRob3JpdHkxIzAhBgNVBAMTGlN0YXJ0Q29tIENsYXNzIDEgQ2xp ZW50IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvX3a98OifYP2W4L921tf rh4bdcC1Ga+YJKy7V3nYNewJHnzMlBsK0Hb8Dm4Wo3FZpylcYa1MJGT10QMGWaLER3xCIuRR +8eklf/EqeZWRLojJ7zBRtjMywPOCelrOU+DX12dKp+Ez4J6919rz1UudTO1GvZyCYJ/I706 2uHsskM8b7gPxmcCoO1UHwwpgkvpCArJWGFoFzjLdsZbErJcS3HtAhlkbE/BKTMrdYg35Uo1 2SLBO5tbk8h2imbKTC8iMs+pskrvI/AVlh6QoTTXk6xboVX6zgMgzxSVVLymQiygYYm0y5aM svi2raFhC643SOGvErWWPPnSEfbeAD1xswIDAQABo4IBZDCCAWAwDgYDVR0PAQH/BAQDAgEG MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDASBgNVHRMBAf8ECDAGAQH/AgEAMDIG A1UdHwQrMCkwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3Nmc2NhLmNybDBmBggr BgEFBQcBAQRaMFgwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTAwBggr BgEFBQcwAoYkaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvY2EuY3J0MB0GA1UdDgQW BBQkgWw5Yb5JD4+3G0YrySi1J0htaDAfBgNVHSMEGDAWgBROC+8apEBbpRdphzDKNGhD0EGu 8jA/BgNVHSAEODA2MDQGBFUdIAAwLDAqBggrBgEFBQcCARYeaHR0cDovL3d3dy5zdGFydHNz bC5jb20vcG9saWN5MA0GCSqGSIb3DQEBCwUAA4ICAQCL4/eH7AGLhK0PAQJbnOEjJyMEvTTw cAJuUh/bodjQl06u4putYOxdSyIjSP/sKt+31LmjG8+IO1WqykE4H/Lm7NKezWVnCHuwb3pt gFmlwbMbGkU2MOZBtwzfKXdYUhFLhaE2uw5jXhXvLYitQay962wP5uPI6eAIhV4L8aaya1u4 s7MnrTq0Rz25FuGNO79vTHYWj797tSRC8rM16js4yGKOLFpQvIg0F8IElv57b1stp+C7omqM 5Qn15dePbSnqr8Jb65WtmJJbnv6rlqfY/aLuE/zmNAlzLmPgfMDStKIXdg+EoYBZTEo8wBUa BxihfNbJ069ndQOxMNNqBelEMgpAtmjTbCuXFjqIwWq+XOx6ZV/Wh2FAmaLsSHlNvEjjSQMZ wE4EeHCdo66ZmEs/5JYlCeOkulKVQ6P3m5/XOj2jP17Q2AgmjP+11+sHN7PvrG0OwrQp9QMe 3X+rn0G8MjtFfqBWvR9CgLIxzM3MJNxFdgdjS2rYnShP5uxvqwfZvhZVYCIkqdJhpYON0DvS odfiar0wiM79mySZJjzC0CTbiisBzS/BeBhqeo2wFfli/iw3hn1XKvAx0ty6w/scmBF0AYqm RHYj1TjMSw0lAl7AztLglqWjUPI+sukvadMRPxmtKXlS2nVR4an/Z16imsZ69+fFYH68c1CK 7zmjozCCBPcwggPfoAMCAQICEGPKwxkQcAfNHxuyTp+gD8wwDQYJKoZIhvcNAQELBQAwdTEL MAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0Q29t IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAxIENs aWVudCBDQTAeFw0xNjA1MjEwMDE3MDlaFw0xOTA4MjEwMDE3MDlaMEAxGzAZBgNVBAMMEmku Z3Jva0Bjb21jYXN0Lm5ldDEhMB8GCSqGSIb3DQEJARYSaS5ncm9rQGNvbWNhc3QubmV0MIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAoYYlhqtcVPaI5BU1UTWTzpRI/w2jkAq5 KGx4m8a0hYOeT/rO1IiFU8QqEg+17ygK2i5eFAk6Vbe54hXC8hfEP8a3JjCcNhPURA0HsTiH 31DAgZv50G8BYQMubml9FMHV+inthbwyWfrDIADM6AuOaqhohZnHb2vL2h4VgJHh9dnh0MQr DjJXcTaE4k6+VRrEaDW00V4saSYzjlLedrw9F9m2hntYE9dP9Eqros5r5XYv2WRlJMsKSfBy k2hrMIeCX6fkXvs5lw8FjdW/6GZlG+VyckAHwtyig92kLWj5GGb+PsSkFR9lHZ6d4SqRtGnr X5i5c7+yO1EeFdWTulQSCwIDAQABo4IBtjCCAbIwDgYDVR0PAQH/BAQDAgSwMB0GA1UdJQQW MBQGCCsGAQUFBwMCBggrBgEFBQcDBDAJBgNVHRMEAjAAMB0GA1UdDgQWBBSeE/ViLQNUr8n+ O2ZP3xm3TmFVPjAfBgNVHSMEGDAWgBQkgWw5Yb5JD4+3G0YrySi1J0htaDBvBggrBgEFBQcB AQRjMGEwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLnN0YXJ0c3NsLmNvbTA5BggrBgEFBQcw AoYtaHR0cDovL2FpYS5zdGFydHNzbC5jb20vY2VydHMvc2NhLmNsaWVudDEuY3J0MDgGA1Ud HwQxMC8wLaAroCmGJ2h0dHA6Ly9jcmwuc3RhcnRzc2wuY29tL3NjYS1jbGllbnQxLmNybDAd BgNVHREEFjAUgRJpLmdyb2tAY29tY2FzdC5uZXQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5z dGFydHNzbC5jb20vMEcGA1UdIARAMD4wPAYLKwYBBAGBtTcBAgUwLTArBggrBgEFBQcCARYf aHR0cHM6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeTANBgkqhkiG9w0BAQsFAAOCAQEABj7z gikcowksyBx01urOlbVzBQYEuDTVaTmARQeIsQEkbvorJQ3Pna+38UL2tMoNoIYpGGo+9OwS 13knWprlYPHDD/4XYoPCsnPRHTfQItYeUTcWvG48YykD8XE9OLEhTY2P5yv0blumxyDPuRnD kyeWsoFoDVUo4miLAaY4nuos9oYRd0Kqznt88UmbwDQc4Id3uGf83nJCPmyZfd07enMVCyL/ uC8ThSHxBuK1lag1hQTFlBI8LsWF/+ZMQtUxTkmNxy3gIAYL/vOnsJTx+HV6Wa7V0ZxYbjzq jR1oIkJRye/G8LUykc7/uF8KYS1CRlts+9BeP98xXOGOrc6EezGCApwwggKYAgEBMIGJMHUx CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBD bGllbnQgQ0ECEGPKwxkQcAfNHxuyTp+gD8wwDQYJYIZIAWUDBAIBBQCggeQwGAYJKoZIhvcN AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMTIyMTUwNDQ3WjAvBgkqhkiG 9w0BCQQxIgQg+BICe0+57VTyHT+fTiJUnxV4Fws8gLKVYV6bCJC8CBIweQYJKoZIhvcNAQkP MWwwajALBglghkgBZQMEASowCwYJYIZIAWUDBAEWMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwDQYJKoZIhvcNAQEBBQAEggEAGd8o5vMm5JpGhcmY2l1FyR9LhOiXEY1YouQGMLhTzYMs xLNes0dDzSFQGlZEpP+XCRAwJdCrWmrpC7iXVTO+bW5g4bE9w1UlaWjiTEJCoXUZRIitN6H8 +8bKuET3wYuJNbf/f+tAZV0X9yMn0GHbPtH58Xhkl+9ndjZdACFDnHdbGjiiFVA9oL14J3XM W6/qQ82dRysNNiAzBA3r4L6ws227xMelxxD+cvrMFlFfvCVioH85jN+U/kfMXqLOd/DL7Hsx XDazWmqO3snsuXM0AigyekuttFSngvWQOtwiZ1VQkdz5FuTAHZ36sg1mIcrdDKgQjQnXDogf hfElgzEMAg== --+HP7ph2BbKc20aGI-- From nobody Tue Nov 22 07:55:34 2016 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 50F9B12968B for ; Tue, 22 Nov 2016 07:55:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.399 X-Spam-Level: X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3euXgZaTJmfn for ; Tue, 22 Nov 2016 07:55:27 -0800 (PST) Received: from mail-io0-x229.google.com (mail-io0-x229.google.com [IPv6:2607:f8b0:4001:c06::229]) (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 375AD1295F0 for ; Tue, 22 Nov 2016 07:55:27 -0800 (PST) Received: by mail-io0-x229.google.com with SMTP id s15so6211026ioi.2 for ; Tue, 22 Nov 2016 07:55:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Dv6wUaJ3HZap83mtL6biHFNc44PEkeT/VZ7tqCSgz8o=; b=YRF0Xf9odczl7Rp3HlGaeQB85CKR23Lr1vX6AXYsU+DQdpOMQxXWXfbJeFf+Yuw9zD JiQ46MNlsw5kRpEYsPcZ3J9uqEepeq5WTUPRTunvqqD2Vd9bsLY8j5mnC8OWU145Fg2P 82g5a+thzZZ/ZUe6+8Vu8V3GiwknT87Q+JkhBaBlDUdP+coYR2zMv71X04CBWxkVm7RB rFp4uBZc+TVCFEcPcbis6N+7e0M3mT3sCgXCHJZB6MOp9LxVB53HqpD2B/xaKdYUlp8v wLTq2fjZPEU5Z8Ez1V/BMQwz6Hwl0ysVJ0roJm8NZiJckT5TOu0AUDqbaEeZqxFhMDx+ 3rRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Dv6wUaJ3HZap83mtL6biHFNc44PEkeT/VZ7tqCSgz8o=; b=EN14ODKifHel+VjiiJhoi+0Rm2QMK8jG6olXaH+7BvZ58EZ4K2CnQhqB/zWzHJQVhp PlXFFyfgbosejDZ+kbwLutMybOFi7+yl1EE10xWZnByBH/IijboaMQaYmuIogGvWHAo7 8wZvgICjsaPFz86w1AtpD6XkklrvAzhfGxkOAqYRI7UImwbHxnDe2pvi/I0nj9i4wPa1 qdGoUoM7bDqsGRBYEAgbKIBS+KAzmS+lUVcveRWoemIRUHTE7YijlDBSBOc7uV69PqH1 ssfvkHgo5epbKuJhf9369kJV3duiPVpfe+STJzvVfBwmAXOgvug6G1EMO3gjDCvsubjP cOXw== X-Gm-Message-State: AKaTC001F1QvFj8Y8RPYBRGN/o9oOENfdz0SZ9Rmrlfv5fbvmmFr0ZEp+zTutq68aVMmKAKkSotUwtHnQJYstw== X-Received: by 10.107.44.5 with SMTP id s5mr9847998ios.10.1479830126543; Tue, 22 Nov 2016 07:55:26 -0800 (PST) MIME-Version: 1.0 Sender: mglt.ietf@gmail.com Received: by 10.107.32.10 with HTTP; Tue, 22 Nov 2016 07:55:25 -0800 (PST) In-Reply-To: <20161122150447.GA21794@odin.ULTHAR.us> References: <20161122150447.GA21794@odin.ULTHAR.us> From: Daniel Migault Date: Tue, 22 Nov 2016 10:55:25 -0500 X-Google-Sender-Auth: erKTAzf8JbmNKC_FlHZmqeEELQ0 Message-ID: To: Scott Schmit Content-Type: multipart/alternative; boundary=001a11394490056e110541e5cd24 Archived-At: Cc: tls Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 15:55:33 -0000 --001a11394490056e110541e5cd24 Content-Type: text/plain; charset=UTF-8 I have a small preference for TLS 1.3. On Tue, Nov 22, 2016 at 10:04 AM, Scott Schmit wrote: > On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG > should rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-rebranding-aka-pr612-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to > not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this > decision on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. > > I find it compelling that if we lived in an alternate universe where we > had SSL 1996, TLS 1999, and a recently-published TLS 2006 or TLS 2008, > there would have been a lot less inertia about switching to a later > version. I find is very optimistic given our history that we could > manage two TLS versions in a year. If that ever happened, though, we > could do 2019.1 (as an increment) or 2019.11 (for the month). > > Barring that, I'd prefer TLS 4, since that gets us out of the version > confusion swamp. It would seem that almost nobody outside the security > community understands the distinction between SSL and TLS; so if we call > it TLS 4, we'll probably see it referred to as SSLv4. And that wouldn't > be horrible. If we call it TLS 2 or TLS 2.0, some might refer to it as > SSLv2. That would obviously be very bad. > > While it's nice to able to look up information about TLS 1.3 drafts, > most of that information is going to be inaccurate anyway, so I don't > see that as a compelling reason to stick to it. Granted, you have > specific buzz for "TLS 1.3 is going to really improve things" but that's > fairly easy to translate to "the new version of TLS is going to really > improve things". > > The distinction between 2 vs 2.0 seems pretty minor. SSLv2 is 2.0 and > SSLv3 is 3.0, but few write it that way. > > Thus my ranked preference would be: > > TLS 2017 > TLS 4 > TLS 1.3 > TLS 2 or TLS 2.0 > > But if I'm limited to a top choice from the list, then "Rebrand TLS 4" > > -- > Scott Schmit > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11394490056e110541e5cd24 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have a small preference for TLS 1.3.

On Tue, Nov 22, 2016 at 10= :04 AM, Scott Schmit <i.grok@comcast.net> wrote:
On Fri, Nov 18, 2016 at 11:12:48AM= +0900, Sean Turner wrote:
> At IETF 97, the chairs lead a discussion to re= solve whether the WG should rebrand TLS1.3 to something else.=C2=A0 Slides = can be found @ h= ttps://www.ietf.org/proceedings/97/slides/slides-97-tls-rebrandin= g-aka-pr612-01.pdf.
>
> The consensus in the room was to leave it as is, i.e., TLS1.3, and to = not rebrand it to TLS 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this d= ecision on the list so please let the list know your top choice between: >
> - Leave it TLS 1.3
> - Rebrand TLS 2.0
> - Rebrand TLS 2
> - Rebrand TLS 4
>
> by 2 December 2016.

I find it compelling that if we lived in an alternate universe where= we
had SSL 1996, TLS 1999, and a recently-published TLS 2006 or TLS 2008,
there would have been a lot less inertia about switching to a later
version.=C2=A0 I find is very optimistic given our history that we could manage two TLS versions in a year.=C2=A0 If that ever happened, though, we<= br> could do 2019.1 (as an increment) or 2019.11 (for the month).

Barring that, I'd prefer TLS 4, since that gets us out of the version confusion swamp.=C2=A0 It would seem that almost nobody outside the securit= y
community understands the distinction between SSL and TLS; so if we call it TLS 4, we'll probably see it referred to as SSLv4.=C2=A0 And that wo= uldn't
be horrible.=C2=A0 If we call it TLS 2 or TLS 2.0, some might refer to it a= s
SSLv2.=C2=A0 That would obviously be very bad.

While it's nice to able to look up information about TLS 1.3 drafts, most of that information is going to be inaccurate anyway, so I don't see that as a compelling reason to stick to it.=C2=A0 Granted, you have
specific buzz for "TLS 1.3 is going to really improve things" but= that's
fairly easy to translate to "the new version of TLS is going to really=
improve things".

The distinction between 2 vs 2.0 seems pretty minor.=C2=A0 SSLv2 is 2.0 and=
SSLv3 is 3.0, but few write it that way.

Thus my ranked preference would be:

TLS 2017 > TLS 4 > TLS 1.3 > TLS 2 or TLS 2.0

But if I'm limited to a top choice from the list, then "Rebrand TL= S 4"

--
Scott Schmit

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a11394490056e110541e5cd24-- From nobody Tue Nov 22 08:35:12 2016 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 BE6791296CF for ; Tue, 22 Nov 2016 08:35:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 NdoKaehDlOY6 for ; Tue, 22 Nov 2016 08:35:03 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (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 5A10E1296CD for ; Tue, 22 Nov 2016 08:35:03 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id c47so15457179qtc.2 for ; Tue, 22 Nov 2016 08:35:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=EgG673OGsh+VdxC2NRHsssCmJUOa4iugjOmeNZ7HAS4=; b=KZjIYU1aaTdDDJqKPFjGRfjcmklcjaTfcpXBhwCqH3ZVk2MR60yBK7rN6saOlcSOcw JbIKA9PlH9OpyrFX9uSvzPB/RwnhAeCRtyYrhIlKXG+wgp4+Mt26El88SHSCfIA20kSy ZeTjH/Jifu8x6Etr0g3AKM077fbs/BTjwxLlo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=EgG673OGsh+VdxC2NRHsssCmJUOa4iugjOmeNZ7HAS4=; b=WzSjmMrGWY1j2QDtieigFQrK+x/az2ef4gOB1FZowxIpoaO9QHObf3dzqBuWgZw6g0 OpNXZq1TV082rttXQs1oZf+gXS/0oQHrLAaISevdPDYpiUr4G3upa01uRXMRdedcg53x fvjwnRIPLNdtiC81QkxgmQ+RTB+obzOhs1LzkLygUCLdW/iafIAp596W2t/vzHVGOxNG 9vPvGzlftTSxADcYZAMxFiqywl5Rou0d7k+duhvWnYuTUKrLbO4C9tKrWNCoLjNaKMeK rx2nBuFHirHxFJYfUVE2K+wY4tnYiJtsCze1HT9nBTf0kbZDuQFkH1ywWZHhue5WY7xo kYWA== X-Gm-Message-State: AKaTC03odyAcB9diIcLvUIS2Yvb3l5RufGKuDigV44DaC2+UR4v0cHMxTO8fzKdusK3/Bw== X-Received: by 10.200.35.46 with SMTP id a43mr13757352qta.20.1479832502339; Tue, 22 Nov 2016 08:35:02 -0800 (PST) Received: from [172.16.0.92] ([96.231.230.70]) by smtp.gmail.com with ESMTPSA id x13sm14116151qkb.45.2016.11.22.08.35.01 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 22 Nov 2016 08:35:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <7F6ED934-C75A-498E-96F3-B0A4E1913A3E@sn3rd.com> Date: Tue, 22 Nov 2016 11:35:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <89A7D7C0-5DB6-464C-8927-FAEF19DE7009@sn3rd.com> References: <7F6ED934-C75A-498E-96F3-B0A4E1913A3E@sn3rd.com> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] housekeeping: uplift RFC 5289 to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 16:35:10 -0000 Seeing no objections I=E2=80=99ll get this process underway. spt > On Nov 15, 2016, at 20:10, Sean Turner wrote: >=20 > Note that Russ pointed out during the meeting that even though we can = use this process a new RFC # will be minted at the end of the process. >=20 > spt >=20 >> On Nov 14, 2016, at 10:36, Sean Turner wrote: >>=20 >> This email addresses the "Uplifting=E2=80=9D bullet on slide 6 of the = chair slides = (https://www.ietf.org/proceedings/97/slides/slides-97-tls-tls-wg-chair-sli= des-00.pdf); this is entirely procedural (i.e., there=E2=80=99s really = no technical ). >>=20 >> The cipher suite registry's new "WG recommended=E2=80=9D column's = =E2=80=9CY" values are being populated with cipher suites that are on = standards track. The notable exceptions are the EC-based AES-GCM = ciphers defined in RFC 5289, which is an informational RFC. This point = is buried in an earlier version of draft-ietf-tls-tls13 and now in the = soon to be draft-ietf-tls-iana-registry-updates (was = draft-sandj-tls-iana-registry-updates); the complete list of the pet-TLS = 1.3 suites can be found here: = https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01#secti= on-6. >>=20 >> We can uplift RFC 5289 to PS from Informational with what essentially = amounts to an IETF LC; we don't need a new draft (there's no errata). = We want to know if there are any objections to starting this process = please post a message to the list by November 21st if you object (and = why). >>=20 >> Please note the following: >>=20 >> - This "action" is similar to what we're doing with 4492bis (it too = is being moved to standards track) it's just that we can use this other = process. >>=20 >> - RFC 7525, which was published through the UTA WG and is a BCP btw, = already 2119-RECOMMENDs the ciphers. >>=20 >> - RFC 7540 (aka HTTP/2) MUSTs one of the RFC 5289 cipher suites. >>=20 >> spt >=20 From nobody Tue Nov 22 10:58:59 2016 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 42CA2129B18 for ; Tue, 22 Nov 2016 10:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no 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 0izcGWDEjHIO for ; Tue, 22 Nov 2016 10:58:56 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56F5212956B for ; Tue, 22 Nov 2016 10:58:56 -0800 (PST) Received: from neoplankton.picty.org (unknown [80.12.39.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id E574E54248 for ; Tue, 22 Nov 2016 18:58:43 +0000 (UTC) Date: Tue, 22 Nov 2016 20:01:06 +0100 From: Olivier Levillain To: tls@ietf.org Message-ID: <20161122190101.GA19978@neoplankton.picty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [TLS] Draft 18 review: Downgrade protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 18:58:58 -0000 Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = Donwgrade protection = On P.32 (section 4.1.3), the part about downgrade protection mechanism is not clear enough. As I understand it, the modified server_random only occurs with a ServerHello indicating TLS 1.2 or below. Moreover, a TLS 1.2 client should only abort the handshake with the TLS 1.1 value, which is not clear in the explanation. Finally, the ServerKeyExchange is only defined in TLS 1.2 or below, so it would be better to add some precision. Here is a proposal to make these points more explicit: TLS 1.3 has a downgrade protection mechanism embedded in the server's random value. TLS 1.3 server implementations MAY respond to a ClientHello indicating only support for TLS 1.2 or below with a ServerHello containing the appropriate version field. TLS 1.3 server implementations which respond with a TLS 1.2 ServerHello, MUST set the last eight bytes of their Random value to the bytes: 44 4F 57 4E 47 52 44 01 TLS 1.3 server implementations which respond with a ServerHello indicating support for TLS 1.1 or below SHOULD set the last eight bytes of their Random value to the bytes: 44 4F 57 4E 47 52 44 00 TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check that the last eight octets are not equal to either of these values. TLS 1.2 clients SHOULD also check that the last eight bytes are not equal to the second value if the ServerHello indicates TLS 1.1 or below. If a match is found, the client MUST abort the handshake with an "illegal_parameter" alert. This mechanism provides limited protection against downgrade attacks over and above that provided by the Finished exchange: because the ServerKeyExchange, a message present in TLS 1.2 and below, includes a signature over both random values, it is not possible for an active attacker to modify the randoms without detection as long as ephemeral ciphers are used. It does not provide downgrade protection when static RSA is used. I can propose a PR if this makes sense to the WG. Olivier Levillain From nobody Tue Nov 22 10:59:27 2016 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 801C4129B2E for ; Tue, 22 Nov 2016 10:59:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no 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 5t8Ziwe2FQmW for ; Tue, 22 Nov 2016 10:59:25 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B62CA129B27 for ; Tue, 22 Nov 2016 10:59:24 -0800 (PST) Received: from neoplankton.picty.org (unknown [80.12.39.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id 37B7454248 for ; Tue, 22 Nov 2016 18:59:22 +0000 (UTC) Date: Tue, 22 Nov 2016 20:02:04 +0100 From: Olivier Levillain To: tls@ietf.org Message-ID: <20161122190158.GB19978@neoplankton.picty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [TLS] Draft 18 review : Extensions and message reuse X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 18:59:26 -0000 Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = Extensions and message reuse = We were sorry to find that some TLS 1.2 extensions were reused with a different meaning, or that some TLS 1.3 extensions were context dependent, which does not allow for a clear separation between the parsing step (which might lead to a decode_error alert) and the message validation step (which might lead to an invalid_parameter alert). It is especially disappointing since the choice made for the ciphersuites is a very clean one. The first example of such a problem is the signature_scheme and signature_algorithms enums. In practice, the signature_algorithm must contain information valid for TLS 1.2 and TLS 1.3, but the exact meaning is not the same in both cases. It would be cleaner to have a new, separate extension called signature_scheme, defining the new enum. This way, a TLS 1.2/1.3 client implementations would send both extensions. We would spend 10 bytes on the wire, but it is not that important for the first message which can be kept reasonably long (and which is sometimes padded via the corresponding extension...) Another example is the key_share extension: it is in fact made of three different extensions, depending on the message where it is included. It would be simpler for a (almost-)stateless parser* to either use three different extensions or to use the same content each time. In the second case, the extension would each time consist of a list of (group + optional keyshare). The advantages of such a unified keyshare extension would be: - stateless parsing* - no reuse of supported_groups which can be merged with key_share - no more validation complexity since higher-level checks were already required (the groups sent by HRR did not came with a key share for example). The major con one might see is that the server can not advertise its supported groups in an encrypted manner anymore (since supported_groups is not used anymore). However, we do believe simplifying the implementation is worth it. * Of course the parser still has to use the extension id to know how to parse the value, but it would not need to have broader context (the message where the extension is included). In other words, we would like select syntax in structs to only use local information. I can try and propose a PR for each extension if there is an interest in the WG. Olivier Levillain From nobody Tue Nov 22 11:01:30 2016 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 7347F1295E9 for ; Tue, 22 Nov 2016 11:01:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no 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 ek4T6QEvB3R2 for ; Tue, 22 Nov 2016 11:01:19 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 294E0129B2F for ; Tue, 22 Nov 2016 11:01:19 -0800 (PST) Received: from neoplankton.picty.org (unknown [80.12.39.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id 35AAC54248 for ; Tue, 22 Nov 2016 19:01:17 +0000 (UTC) Date: Tue, 22 Nov 2016 20:03:59 +0100 From: Olivier Levillain To: tls@ietf.org Message-ID: <20161122190344.GC19978@neoplankton.picty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [TLS] Draft 18 review : Hello Retry Request and supported groups cache X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:01:20 -0000 Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = HRR and supported groups cache = In 4.2.4 (P.41), a server can send a supported_groups extension to "update the client's view of its preference" in its ServerHello. Since this behaviour is completely left to the client's discretion, it does not seem a very relevant policy from the server: either the server accepts one of the proposed groups, or it sends an HRR. We do not think the middle ground (OK for this group, but I would prefer this other one) is relevant, so the sentence should be removed. Moreover, as far as I could understand, there is no indication in the specification that a client should remember the preference of the server in case it receives a HRR, which there would definitely make sense. Such text could go in 4.1.4. I can propose a PR for this point. Olivier Levillain From nobody Tue Nov 22 11:04:30 2016 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 73C74129B23 for ; Tue, 22 Nov 2016 11:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no 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 LkZ88qx_hCG2 for ; Tue, 22 Nov 2016 11:04:21 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876C9129B46 for ; Tue, 22 Nov 2016 11:04:18 -0800 (PST) Received: from neoplankton.picty.org (unknown [80.12.39.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id E4B5654248 for ; Tue, 22 Nov 2016 19:04:15 +0000 (UTC) Date: Tue, 22 Nov 2016 20:06:55 +0100 From: Olivier Levillain To: tls@ietf.org Message-ID: <20161122190651.GD19978@neoplankton.picty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [TLS] Draft 18 review : PSK and PSK Binder X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:04:27 -0000 Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = PSK and PSK Binder = P.35 (4.2), it is specified that the pre_shared_key extension must be the last extension in the ClientHello, because of the way the PSK Binder is computed. This seems very hackish and will most certainly lead to implementation errors. However, I understand that it was not easy to propose a cleaner mechanism while keeping a common flow between *DHE and PSK modes. Yet, we would have preferred that PSK would not be MTI as stated in the end of the document (P.81, section 8.2). In previous versions PSK and resumption was not MTI, so it might be logical to keep it this way. Alternatively, we might propose a profile defining a simpler TLS subset. Regarding the definition of the PSK Binder (P. 45 and 46, section 4.2.6.1), we found it very hard to read, since the binding value is said to be computed as the Finished message, but differently. In particular, it would be useful to give the relevant information (I believe the Handshake Context is called transcript in this section, and it would be important to explicit the Hash to use), instead of implying it. It would not take much space in the document, but it would ensure implementers know how to compute the binder. Olivier Levillain From nobody Tue Nov 22 11:05:08 2016 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 462C9129E85 for ; Tue, 22 Nov 2016 11:05:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no 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 lqUinAQFZO7Z for ; Tue, 22 Nov 2016 11:05:05 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED812129B4C for ; Tue, 22 Nov 2016 11:04:42 -0800 (PST) Received: from neoplankton.picty.org (unknown [80.12.39.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id 2A7C954248 for ; Tue, 22 Nov 2016 19:04:40 +0000 (UTC) Date: Tue, 22 Nov 2016 20:07:22 +0100 From: Olivier Levillain To: tls@ietf.org Message-ID: <20161122190720.GE19978@neoplankton.picty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [TLS] Draft 18 review : 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:05:06 -0000 Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = 0-RTT = In 4.2.8 (P.47), the server receiving early_data "can behave in one of two ways"... followed by three cases. Beside the typo, the first case could be phrased differently. Actually, it reads - Ignore the extension and return no response. This indicates that the server has ignored any early data and an ordinary 1-RTT handshake is required. Since an ordinary 1-RTT handshake will require the server to actually send a response (the ServerHello), it might be better to put it this way: - Ignore the extension and return a standard 1-RTT ServerHello. This indicates that the server has ignored any early data and an ordinary 1-RTT handshake is required. Olivier Levillain From nobody Tue Nov 22 11:05:31 2016 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 2F897129683 for ; Tue, 22 Nov 2016 11:05:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no 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 rCf66uFjRl9t for ; Tue, 22 Nov 2016 11:05:29 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44852129B21 for ; Tue, 22 Nov 2016 11:05:28 -0800 (PST) Received: from neoplankton.picty.org (unknown [80.12.39.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id 62A5E54275 for ; Tue, 22 Nov 2016 19:05:26 +0000 (UTC) Date: Tue, 22 Nov 2016 20:08:09 +0100 From: Olivier Levillain To: tls@ietf.org Message-ID: <20161122190758.GG19978@neoplankton.picty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [TLS] Draft 18 review : Message order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:05:30 -0000 Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = Message order = I believe the message P.27 section 4 is important, but not sufficient. As already expressed on the list, a formal automaton should be provided in the spec. I think Ekr said there was some work in progress in this area. Is this a goal for the final specification? Olivier Levillain From nobody Tue Nov 22 11:05:51 2016 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 AD5E3129B40 for ; Tue, 22 Nov 2016 11:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no 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 lERPGCXf7aCc for ; Tue, 22 Nov 2016 11:05:49 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72FFB129B2B for ; Tue, 22 Nov 2016 11:05:49 -0800 (PST) Received: from neoplankton.picty.org (unknown [80.12.39.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id EED9354275 for ; Tue, 22 Nov 2016 19:05:44 +0000 (UTC) Date: Tue, 22 Nov 2016 20:08:26 +0100 From: Olivier Levillain To: tls@ietf.org Message-ID: <20161122190822.GH19978@neoplankton.picty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [TLS] Draft 18 review : Message splitting and interleaving X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:05:50 -0000 Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = Message splitting and interleaving = How to split and interleave subprotocols in TLS has not been clearly specified in the past, and it would be useful to be crystal clear on this point. In the specification, the subject is first presented in 4.5 (P.61): Handshake messages sent after the handshake MUST NOT be interleaved with other record types. That is, if a message is split over two or more handshake records, there MUST NOT be any other records between them. But I am wondering why this text only concern "messages after the handshake". It should always be the case! It is next present in section 4.5.3 (P.64): Handshake messages MUST NOT span key changes. Because the ServerHello, Finished, and KeyUpdate messages signal a key change, upon receiving these messages a receiver MUST verify that the end of these messages aligns with a record boundary; if not, then it MUST terminate the connection with an "unexpected_message" alert. And then in section 5 (mostly P.64 and P.65) plus a repetition P.69. It is worth noting that this specific point was (at least partially) the origin of several security issues: - the alert attack (https://www.mitls.org/pages/attacks/Alert); - Heartbleed (where OpenSSL answered with a fragmented record whereas it was not the spirit of the spec); - the OpenSSL Downgrade attack in 2014. Some of this is covered in the current specification, but it might be worth being even stricter: - regarding splitting/merging, they should be forbidden by default; - the default would apply to alerts (currently, the spec states that alerts MUST not be split, but they should not be merged either for simplicity's sake and since it is useless); - incidentally, the default behaviour would apply to Heartbeat, as was the intent of the specification; - ApplicationData should be considered as a stream with possibly 0-length records - Handshake messages should either come as a sequence of multiple *entire* messages, or as a fraction of *one* message. That is, the number of HS messages inside one record should either be a round number or strictly less than 1. These constraints can be expressed in 5.1 and cover most of the problematic cases. They are easy to check and to enforce. However, the problem of the OpenSSL Downgrade flaw (where the first record containing the beginning of the ClientHello was cut before the ClientHello.version field) will still stand, but there is no simple way to fix this, since version negotiation can now happen anywhere in the ClientHello extensions, so it might be impossible to enforce that the client versions are sent in the first record. I might volunteer some text if there is an interest of the WG. Olivier Levillain From nobody Tue Nov 22 11:07:10 2016 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 126E5129B59 for ; Tue, 22 Nov 2016 11:07:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no 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 dzgrmSmOfTDU for ; Tue, 22 Nov 2016 11:07:06 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D87512960B for ; Tue, 22 Nov 2016 11:06:43 -0800 (PST) Received: from neoplankton.picty.org (unknown [80.12.39.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id 9399E54275 for ; Tue, 22 Nov 2016 19:06:31 +0000 (UTC) Date: Tue, 22 Nov 2016 20:09:06 +0100 From: Olivier Levillain To: tls@ietf.org Message-ID: <20161122190846.GI19978@neoplankton.picty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [TLS] Draft 18 review : Minor remarks and typos X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:07:08 -0000 Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = Minor remarks = - P.14 (section 2): "Everything after this phase is encrypted" => "is protected" (since we also have integrity protection). - P.14 (section 2) and P.20 (section 2.3): the psk_key_exchange_modes extension is called "pre_shared_key_modes". - P.21 (section 2.3): Add a reference to the relevant section for "early exporter secret"? - P.41 and 42 (4.2.5): The fact that clients can send an empty client_shares vector is repeated 30 lines apart. Is it really needed? - P.43 (section 4.2.5.2): during the description of ECDHE parameters with secp*, the paragraph Although X9.62 supports multiple point formats, any given curve MUST specify only a single point format. All curves currently specified in this document MUST only be used with the uncompressed point format (the format for all ECDH functions is considered uncompressed). seems to imply that all ECDHE points are uncompressed, which is not the case. I would replace "All curves currently specified in this document" with "secp256r1, secp384r1 and secp521r1 curves". Similarly, I would remove the parenthesis. - P.44 (4.2.6): Unless I am mistaken, the identity field in the extension is the "ticket" (when using the older terminology). However, the term ticket is used in different places afterwards, without a proper definition. It might make sense to add a word in the identities definition. - P.44 (4.2.6): Similarly, it would be clearer to say "externally established PSKs" (as in P.45) instead of "external tickets". - P.44 (4.2.6) Similarly, instead of saying that a binder must be given "for each PSK offered", it might be clearer to say "for each PSK identity offered". (Sorry for th nitpick, but I believe it is important to be crystal clear in such a document). - P.46 (4.2.7): "Servers MUST NOT select a key exchange mode that is not listed by the client". As I understand it, the server advertises its "selection" by adding the keyshare extension or not. It might be useful to add this precision if I am not mistaken. - P.48 (4.2.8): "the server MUST have accepted a PSK ciphersuite" => since PSK ciphersuites do not exist anymore, should not it be "have accepted to use a PSK key exchange mode" or "have answered with a psk extension"? - P.53 (4.4): The Certificate message definition contains the following text: "Note that certificate-based client authentication is not available in the 0-RTT case." It might make more sense to move this text elsewhere in the section, and to explain it further: does it mean the 1-RTT following the early data must not contain a client authentication? - P.53 (4.4): What are "the pure 1-RTT cases"? - P.54 (4.4.1): Since the specification does not force the certificates to be ordered in the Certificate message anymore, what is the point of adding a SHOULD about the order? On the other hand, the text might include the requirement that all intermediate AC are to be provided in the Certificate message. - P. 55 (4.4.1.1): Since it is now possible to add per-certificate extension, I believe status_request_v2 does not make any sense now. Should not it be clearer to deprecate it with TLS 1.3 and to force multiple OCSP stapling to be made exclusively with multiple status_request extensions (one for each cert)? - P.56 (4.4.1.2): The text "As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable." should be moved elsewhere (e.g. when discussing ClientHello). - It is not clear whether a client can authenticate with a certificate when the server has chosen PSK authentication. P.49 (4.3.2) states that "A server which is authenticating with a certificate can optionally request a certificate from the client." whereas 4.4.2 (P.59) states that "When used with non-certificate-based handshakes (e.g., PSK), the client's signature [in CertificateVerify] does not cover the server's certificate directly." How should this be interpreted? - P.60 (4.4), it is said that "The key used to compute the finished message is computed from the Base key defined in Section 4.4 using HKDF", but we are *in* section 4.4, so there must be a mistake? - P.61 (4.5.1), it is said that "the resumption master secret depends on the client's second flight" but this is only true when the client authenticates itself with a certificate. This point is related to a point sent by Ben Kaduk (https://www.ietf.org/mail-archive/web/tls/current/msg21829.html): "In section 4.5.1 we note that when client auth is not used, servers MAY compute the remainder of the client-sent messages for the transcript so as to issue a NewSessionTicket immediately after the server Finished. Do we want to say anything about why a server might wish to do so?" (https://www.ietf.org/mail-archive/web/tls/current/msg21829.html). to which Ekr answered with "I think I would rather not." - P.63 (4.5.3): The definition of the "request_update" field is unclear. It is said to "indicate that the recipient of [...] should respond". Should not it say "Indicates *whether* the recipient" - P.65 (5.1): "Endpoints supporting other versions" => "earlier"? - P.66 (5.2): the content type if the TLS InnerPlaintext must be non null for the padding to work. This is correctly stated in the end of the specification where 0 is invalid_RESERVED, but it might be useful to add a statement in the type field definition: "Valid content types all have non-null values." - P.67 (5.2): The exact same text is repeated twice in the page: "An endpoint that receives a record that exceeds this length MUST terminate the connection with a "record_overflow" alert." - P.81 (8.1): RSA signature schemes are specified to be MTI for certificates and optionally for CertificateVerify. The precision should also be added for ecdsa_secp256r1-sha256. - P.83 and 85 (8.2): "Client" is supposed to mean that "the server shall not send them". Yet, the cookie extension is marked as Clear, and can be sent in the HRR message. - P.84 (8.2): Since it is said afterwards that truncated_hmac is a dangerous extension, it might be logical to mark it as *not* recommended? - P.84 and 85: I suppose that the order of the extensions in this table is given by the extension id. Yet it might be more practical to sort the table by extension name? - P.105 (B.4): "Do you verify that the RSA padding doesn't have additional data after the hash value? [FI06]" => the attack was about PKCS#1 v1.5, not PSS. Does it still apply, or should the text be amended? - P.105 (B.4): I believe the part about ECDSA "k" parameter states opposing statements, since deterministic ECDSA leads to a non-random k: Do you use a strong and, most importantly, properly seeded random number generator (see Appendix B.2) when generating Diffie-Hellman private values, the ECDSA "k" parameter, and other security- critical values? It is RECOMMENDED that implementations implement "deterministic ECDSA" as specified in [RFC6979]. Would not it be more logical to say: "Alternatively, it is RECOMMENDED..." - P.113 (D.2): There are missing references concerning the analysis of the TLS record layer = Typos = - P.28 (section 4.1.1): a quote is missing after '"psk_key_exchange_modes' - P.46 (4.2.7): "A clients MUST provide" => "client" - P.54 (4.4.1): "If an extension applies the the entire chain" => "to the" - P.58 (4.4.2): "A single 0 byte which servers as the separator" => "serves" - P.63 (4.5.3): "If the request_udate" => request_update - P.86 (8.2): "and the TLS SignatureAlgorithm Registry to list values 4-233 as "Reserved"" => It should be 223 (as 224-255 are reserved for private use) Olivier Levillain From nobody Tue Nov 22 11:09:43 2016 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 6FC23129B2B for ; Tue, 22 Nov 2016 11:09:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 YCV_vtRHUDRv for ; Tue, 22 Nov 2016 11:09:38 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com [IPv6:2607:f8b0:4003:c06::22c]) (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 0BF20129B44 for ; Tue, 22 Nov 2016 11:09:38 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id y198so28766801oia.1 for ; Tue, 22 Nov 2016 11:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=sXJSa30OqxrTYgYj3aea0w1lgd/YnBcY2o5CynnrkiM=; b=l4WxFkbs3DwZ7M76HXs/+BB+cInK9gdHg8zAOpd+eMGiRSM99JZ6s8pglfRczsNX5O RyOceWh77I+uulTBtaXb8sww10wdgG3dj01O0wHc7SySI3eDOgwNr/v8aYmlEqly+ho+ ctiPgUnzPNYatzVti2kpW7eTShiIOFww4iIzI= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=sXJSa30OqxrTYgYj3aea0w1lgd/YnBcY2o5CynnrkiM=; b=Mq/xC1M5vRpq1Vps/9XjiRvTnwMlyZ4TtlIGsbNQnGyXDoGXsvempEHKoAL0Hp4SFT AdCVymH+egLPGD2O4EXCaUD1XcIKXZoygamnCJc68GPuRcpEWW2ZWvUaHXWc287Ibxqf lPqRe2yp7avrMtgtFJa0sl0V/kEZkYT6zn45b6HHlTmxwkZMOYXKbzUPfOo+YK+okQnB vUsoopHP4bUWv2srAayYJMIKpAzVL46Cqhx3V3Te5dQ1Xur0kaMLkioI3TQKUR8VGw5D mvI9QQ4AgkXsjuiQbIj3zSnB+zByXe/604cuvsxlcD5zbvHp57vGfut0tNah9uFhPqUA pWvA== X-Gm-Message-State: AKaTC030V6K7zw33SBN3fCDXdSzBzg6ZGgq3+sUrtSDroQaYC3sCAHLMyaG1C7iIMLhuRVR3 X-Received: by 10.157.36.84 with SMTP id p78mr12975457ota.235.1479841777291; Tue, 22 Nov 2016 11:09:37 -0800 (PST) Received: from mail-oi0-f46.google.com (mail-oi0-f46.google.com. [209.85.218.46]) by smtp.gmail.com with ESMTPSA id 99sm9020959otd.28.2016.11.22.11.09.36 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 11:09:36 -0800 (PST) Received: by mail-oi0-f46.google.com with SMTP id v84so28560951oie.3 for ; Tue, 22 Nov 2016 11:09:36 -0800 (PST) X-Received: by 10.202.252.133 with SMTP id a127mr13043776oii.124.1479841776443; Tue, 22 Nov 2016 11:09:36 -0800 (PST) MIME-Version: 1.0 References: <20161122190344.GC19978@neoplankton.picty.org> In-Reply-To: <20161122190344.GC19978@neoplankton.picty.org> From: Steven Valdez Date: Tue, 22 Nov 2016 19:09:25 +0000 X-Gmail-Original-Message-ID: Message-ID: To: Olivier Levillain , tls@ietf.org Content-Type: multipart/alternative; boundary=001a113de16a6906ef0541e883f0 Archived-At: Subject: Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:09:40 -0000 --001a113de16a6906ef0541e883f0 Content-Type: text/plain; charset=UTF-8 Being able to send supported_groups does allow a server to choose to make a tradeoff between an extra round trip on the current connection and its own group preferences. One example where a server might want to do this is where it believes that X25519 is likely a more future-proof group and would prefer that, but still believes the client's choice of P256 is suitable for this connection. Always requiring an extra round trip might end up being expensive depending on the situation so some servers might prefer to avoid sending an HRR for a slightly more preferred group. I think that requiring the client to maintain state from the supported_groups puts undue requirements on the client, since not all clients keep state between connections, and those that do usually only keep session state for resumption. On Tue, Nov 22, 2016 at 2:01 PM Olivier Levillain < olivier.levillain@ssi.gouv.fr> wrote: > Hi list, > > I am sorry for the very late answer concerning draft 18, but we > (ANSSI) have several remarks after proof-reading the current > specification. > > We are sorry for the multiple long messages. > > If the WG is interested by some of our concerns/proposals, we would be > glad to propose some PRs. > > > = HRR and supported groups cache = > > In 4.2.4 (P.41), a server can send a supported_groups extension to > "update the client's view of its preference" in its ServerHello. > Since this behaviour is completely left to the client's discretion, it > does not seem a very relevant policy from the server: either the > server accepts one of the proposed groups, or it sends an HRR. We do > not think the middle ground (OK for this group, but I would prefer > this other one) is relevant, so the sentence should be removed. > > Moreover, as far as I could understand, there is no indication in the > specification that a client should remember the preference of the > server in case it receives a HRR, which there would definitely make > sense. Such text could go in 4.1.4. > > I can propose a PR for this point. > > > Olivier Levillain > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a113de16a6906ef0541e883f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Being able to send supported_groups does allow a server to= choose to make a tradeoff between an extra round trip on the current conne= ction and its own group preferences. One example where a server might want = to do this is where it believes that X25519 is likely a more future-proof g= roup and would prefer that, but still believes the client's choice of P= 256 is suitable for this connection. Always requiring an extra round trip m= ight end up being expensive depending on the situation so some servers migh= t prefer to avoid sending an HRR for a slightly more preferred group.
<= br>
I think that requiring the client to maintain state from the = supported_groups puts undue requirements on the client, since not all clien= ts keep state between connections, and those that do usually only keep sess= ion state for resumption.

On Tue, Nov 22, 2016 at 2:01 PM Olivier Levillain <olivier.levillain@ssi.gouv.fr> wrote= :
Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


=3D HRR and supported groups cache =3D

In 4.2.4 (P.41), a server can send a supported_groups extension to
"update the client's view of its preference" in its ServerHel= lo.
Since this behaviour is completely left to the client's discretion, it<= br class=3D"gmail_msg"> does not seem a very relevant policy from the server: either the
server accepts one of the proposed groups, or it sends an HRR.=C2=A0 We do<= br class=3D"gmail_msg"> not think the middle ground (OK for this group, but I would prefer
this other one) is relevant, so the sentence should be removed.

Moreover, as far as I could understand, there is no indication in the
specification that a client should remember the preference of the
server in case it receives a HRR, which there would definitely make
sense.=C2=A0 Such text could go in 4.1.4.

I can propose a PR for this point.


Olivier Levillain

_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--001a113de16a6906ef0541e883f0-- From nobody Tue Nov 22 11:11:07 2016 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 3C6DC129AE5 for ; Tue, 22 Nov 2016 11:10:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_FAIL=0.001] autolearn=no autolearn_force=no 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 ZfvWSOkhpmLr for ; Tue, 22 Nov 2016 11:10:50 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4614A129B59 for ; Tue, 22 Nov 2016 11:10:25 -0800 (PST) Received: from neoplankton.picty.org (unknown [80.12.39.49]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id 69D8A54248 for ; Tue, 22 Nov 2016 19:05:04 +0000 (UTC) Date: Tue, 22 Nov 2016 20:07:45 +0100 From: Olivier Levillain To: tls@ietf.org Message-ID: <20161122190738.GF19978@neoplankton.picty.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Subject: [TLS] Draft 18 review : Signature in certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:10:51 -0000 Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. = Signature in certificates = The two paragraphs in 4.4.1.2 P.56 starting with "All certificates" are very far from clear. They require (MUST) some behaviour, which is later reformulated with an unless part. I am not sure of the intent here, but we believe the current text should be rewritten to clearly express the intent of the WG. My comprehension is that the server MUST use only signature schemes described in signature_algorithms, except for the following cases: - for checking the signature in self-signed or trust anchors (since this check is useless, the trust coming from an out-of-band mechanism in this case) - when the only available chains use signature scheme are not known to be supported by the client - the case of SHA-1 is special The same confusion can be found in 4.4.2 P.59 ("If sent by a server...") Olivier Levillain From nobody Tue Nov 22 11:12:28 2016 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 A97F0129B25 for ; Tue, 22 Nov 2016 11:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 rvXmZ2bx7Vw5 for ; Tue, 22 Nov 2016 11:12:25 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 D073C1296D6 for ; Tue, 22 Nov 2016 11:12:23 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id i145so22873173ywg.2 for ; Tue, 22 Nov 2016 11:12:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mhrepxhJD0Txyq8BDtUQYGBV149ASAng0+TkNQPY2L4=; b=mtPmknUnC70UomhXnJPqrkgcqL1g5Xo3jpXYv3KoONNYX2KiGlMt6VFNOvdSFZNl70 kJ+QtK62nu5o87h7pnMDe41vmDTS/ujLertceD/8wEJinsdXgOsKtoujolVC5v/DKZZ2 DuRUGhIxdC69s+Y84aDXvCnOglnXhwDdAjdnL7FhArClqwRBoYwvY2ReqQ6Nsl5zzl2p 5dPTmEKvHDhfhK4TsqMGzZHSeRcRZ9g2qwAIZOq/8LUvP9Llq1C/nDHCW0XWfCqIH53g jWziagFVPUtJH8MT2UvlJRn3iWzKsD99ZkfTejxMork02Uuhu4UxS2Zes9lI5ZIidy52 4SZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mhrepxhJD0Txyq8BDtUQYGBV149ASAng0+TkNQPY2L4=; b=NFUlBhlPdAdLazYNGd52uhxGh6zmmW5sSMESYC5jXrdYGrcfEv0W4Y0OGkrfUoGEWX q1/e8qMtsCjEv6g1ca6ml1CluFlMU6Weyu/VPXtPgXSwpl3qxsvOlC46SjcnXUoCDaUO Ie0TlPDOVjxYEccbxQI7aaWQw/H4Xn9UFsECsHOAwR8QzTyAnepFeUU/fdQWg50lCZsN jh1LR6cHyAcxAYxkpSk7qbjc/SVAC/rxZhM54wZNcdWFl56JbIC/u3lud3QVpwMlq12k lSzv4cvn1uexoJK6XHztwVWn4K9vvQPJrITks9gTv2EeXIe6XrJjL36YXAa/JBUt7QRM dQVA== X-Gm-Message-State: AKaTC01UW36dd6UUaaZtcQ1V6tm9VuPYNTz/oao53NW3BKgiYRPaW7+ke2ypXHXJaBFazQd0fBQQZOwRxtM5Ew== X-Received: by 10.129.108.216 with SMTP id h207mr22492027ywc.52.1479841943077; Tue, 22 Nov 2016 11:12:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.124.214 with HTTP; Tue, 22 Nov 2016 11:11:42 -0800 (PST) In-Reply-To: <20161122190101.GA19978@neoplankton.picty.org> References: <20161122190101.GA19978@neoplankton.picty.org> From: Eric Rescorla Date: Tue, 22 Nov 2016 11:11:42 -0800 Message-ID: To: Olivier Levillain Content-Type: multipart/alternative; boundary=001a114dd36e5771f60541e88d43 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review: Downgrade protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:12:26 -0000 --001a114dd36e5771f60541e88d43 Content-Type: text/plain; charset=UTF-8 Hi Olivier, Thanks for your comments. I do want this section to be clear. It would be very helpful if you formatted this as a PR. That would make it easier to understand the changes in this text. Thanks, -Ekr On Tue, Nov 22, 2016 at 11:01 AM, Olivier Levillain < olivier.levillain@ssi.gouv.fr> wrote: > Hi list, > > I am sorry for the very late answer concerning draft 18, but we > (ANSSI) have several remarks after proof-reading the current > specification. > > We are sorry for the multiple long messages. > > If the WG is interested by some of our concerns/proposals, we would be > glad to propose some PRs. > > > = Donwgrade protection = > > On P.32 (section 4.1.3), the part about downgrade protection mechanism > is not clear enough. As I understand it, the modified server_random > only occurs with a ServerHello indicating TLS 1.2 or below. Moreover, > a TLS 1.2 client should only abort the handshake with the TLS 1.1 > value, which is not clear in the explanation. Finally, the > ServerKeyExchange is only defined in TLS 1.2 or below, so it would be > better to add some precision. Here is a proposal to make these points > more explicit: > > TLS 1.3 has a downgrade protection mechanism embedded in the server's > random value. TLS 1.3 server implementations MAY respond to a > ClientHello indicating only support for TLS 1.2 or below with a > ServerHello containing the appropriate version field. > > TLS 1.3 server implementations which respond with a TLS 1.2 > ServerHello, MUST set the last eight bytes of their Random value > to the bytes: > > 44 4F 57 4E 47 52 44 01 > > TLS 1.3 server implementations which respond with a ServerHello > indicating support for TLS 1.1 or below SHOULD set the last > eight bytes of their Random value to the bytes: > > 44 4F 57 4E 47 52 44 00 > > TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST check > that the last eight octets are not equal to either of these values. > TLS 1.2 clients SHOULD also check that the last eight bytes are not > equal to the second value if the ServerHello indicates TLS 1.1 or > below. If a match is found, the client MUST abort the handshake > with an "illegal_parameter" alert. This mechanism provides limited > protection against downgrade attacks over and above that provided > by the Finished exchange: because the ServerKeyExchange, a message > present in TLS 1.2 and below, includes a signature over both random > values, it is not possible for an active attacker to modify the > randoms without detection as long as ephemeral ciphers are used. > It does not provide downgrade protection when static RSA is used. > > I can propose a PR if this makes sense to the WG. > > > Olivier Levillain > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dd36e5771f60541e88d43 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Olivier,

Thanks for your comments. I= do want this section to be clear.

It would be ver= y helpful if you formatted this as a PR. That would make it easier to under= stand the changes in this text.

Thanks,
= -Ekr




On Tue, Nov 22, 2016 at 11:= 01 AM, Olivier Levillain <olivier.levillain@ssi.gouv.fr>= ; wrote:
Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


=3D Donwgrade protection =3D

On P.32 (section 4.1.3), the part about downgrade protection mechanism
is not clear enough.=C2=A0 As I understand it, the modified server_random only occurs with a ServerHello indicating TLS 1.2 or below.=C2=A0 Moreover,=
a TLS 1.2 client should only abort the handshake with the TLS 1.1
value, which is not clear in the explanation.=C2=A0 Finally, the
ServerKeyExchange is only defined in TLS 1.2 or below, so it would be
better to add some precision.=C2=A0 Here is a proposal to make these points=
more explicit:

=C2=A0 =C2=A0TLS 1.3 has a downgrade protection mechanism embedded in the s= erver's
=C2=A0 =C2=A0random value.=C2=A0 TLS 1.3 server implementations MAY respond= to a
=C2=A0 =C2=A0ClientHello indicating only support for TLS 1.2 or below with = a
=C2=A0 =C2=A0ServerHello containing the appropriate version field.

=C2=A0 =C2=A0TLS 1.3 server implementations which respond with a TLS 1.2 =C2=A0 =C2=A0ServerHello, MUST set the last eight bytes of their Random val= ue
=C2=A0 =C2=A0to the bytes:

=C2=A0 =C2=A0 =C2=A044 4F 57 4E 47 52 44 01

=C2=A0 =C2=A0TLS 1.3 server implementations which respond with a ServerHell= o
=C2=A0 =C2=A0indicating support for TLS 1.1 or below SHOULD set the last =C2=A0 =C2=A0eight bytes of their Random value to the bytes:

=C2=A0 =C2=A0 =C2=A044 4F 57 4E 47 52 44 00

=C2=A0 =C2=A0TLS 1.3 clients receiving a TLS 1.2 or below ServerHello MUST = check
=C2=A0 =C2=A0that the last eight octets are not equal to either of these va= lues.
=C2=A0 =C2=A0TLS 1.2 clients SHOULD also check that the last eight bytes ar= e not
=C2=A0 =C2=A0equal to the second value if the ServerHello indicates TLS 1.1= or
=C2=A0 =C2=A0below.=C2=A0 If a match is found, the client MUST abort the ha= ndshake
=C2=A0 =C2=A0with an "illegal_parameter" alert.=C2=A0 This mechan= ism provides limited
=C2=A0 =C2=A0protection against downgrade attacks over and above that provi= ded
=C2=A0 =C2=A0by the Finished exchange: because the ServerKeyExchange, a mes= sage
=C2=A0 =C2=A0present in TLS 1.2 and below, includes a signature over both r= andom
=C2=A0 =C2=A0values, it is not possible for an active attacker to modify th= e
=C2=A0 =C2=A0randoms without detection as long as ephemeral ciphers are use= d.
=C2=A0 =C2=A0It does not provide downgrade protection when static RSA is us= ed.

I can propose a PR if this makes sense to the WG.


Olivier Levillain

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114dd36e5771f60541e88d43-- From nobody Tue Nov 22 11:15:53 2016 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 CB0F4129B4C for ; Tue, 22 Nov 2016 11:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 bcCccVccnDwW for ; Tue, 22 Nov 2016 11:15:50 -0800 (PST) Received: from mail-yw0-x22f.google.com (mail-yw0-x22f.google.com [IPv6:2607:f8b0:4002:c05::22f]) (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 E6A8412956B for ; Tue, 22 Nov 2016 11:15:49 -0800 (PST) Received: by mail-yw0-x22f.google.com with SMTP id r204so22979160ywb.0 for ; Tue, 22 Nov 2016 11:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kOJHQDSr6ge15URjTirVj4eCPVdZa/3PwtslXgqlPOU=; b=T2o8gTazidim+xFFlnaUpS/gW1CJ/NfwlX/l0LSBQRedX4hEILkn6L5AY3GF7JZFy8 wof+fHpBD8/aRsZYa/Ok0yDBIjwTygvmKAzS8kMk/C+EuJ07t6Wu2BN3SZxG34GdIOdm +fC85JPO2wlBvXS8L3uB2iWO87HX1FflHU/AGsvKAKGW05XgTG1xz1kDDM+rSLIMF715 695u5c5U4efXRuoYq7JZt0lEWZd5CU+mTuJ1BsKa/1ncRcoOAVR+mOyRaNm/WOLaQlpf /C+zeuiT78PjgdqkhKZpVUzVc9rGK0KyQuiB+FB9dXqMbVbisZ68ES2/OXTwrcRWLDHQ 24pg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kOJHQDSr6ge15URjTirVj4eCPVdZa/3PwtslXgqlPOU=; b=UbBXbs9DsZ3ingggfHG9T8QakH0hDNbNFOxc+3/hn4mOZ7HjvEDGAmhjTQ97c+0d1H 3SWrZpiAKfhsm5vojy6rWdZqztZ28hQ/YK/MlOEXwJg2e0utmfs9Xh6soxc1Mf9yk8mJ 3Y0ZVfMwPFbWRNkywaHLpUidjLTfebg7yl23OdHdtOe2kvQ2whtMccEji91XXS5O5wkc dVPVxIe92Z85oVvP0U6KOSfgv293bjqo3f3m4aBwWAmXzvQUNb6CREtwqNB/06HifmvM GauM+jeu46xvCqvSJqQMbuVzzAFEYtyjflrFBMPNYCfdtxJkbZ9nS97FFpBK8CT3IkDr JQ1w== X-Gm-Message-State: AKaTC00wZxBGqZ/mxE5Ib7wn7tdjnpHjmQkdn+s6NzNIfPqr1deQxnvhKdvuzYR4F6YY/3FbWsnNeGnfZNtefQ== X-Received: by 10.129.53.194 with SMTP id c185mr22154200ywa.205.1479842149252; Tue, 22 Nov 2016 11:15:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.124.214 with HTTP; Tue, 22 Nov 2016 11:15:08 -0800 (PST) In-Reply-To: References: <20161122190344.GC19978@neoplankton.picty.org> From: Eric Rescorla Date: Tue, 22 Nov 2016 11:15:08 -0800 Message-ID: To: Steven Valdez Content-Type: multipart/alternative; boundary=001a11421478a1672d0541e89928 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:15:52 -0000 --001a11421478a1672d0541e89928 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 22, 2016 at 11:09 AM, Steven Valdez wrote: > Being able to send supported_groups does allow a server to choose to make > a tradeoff between an extra round trip on the current connection and its > own group preferences. One example where a server might want to do this is > where it believes that X25519 is likely a more future-proof group and would > prefer that, but still believes the client's choice of P256 is suitable for > this connection. Always requiring an extra round trip might end up being > expensive depending on the situation so some servers might prefer to avoid > sending an HRR for a slightly more preferred group. > > I think that requiring the client to maintain state from the > supported_groups puts undue requirements on the client, since not all > clients keep state between connections, and those that do usually only keep > session state for resumption. > This matches my view as well. I agree that the client should not be require to keep state. I do not believe that the draft requires this, but if someone thinks otherwise, please send a PR to fix. -Ekr > > On Tue, Nov 22, 2016 at 2:01 PM Olivier Levillain < > olivier.levillain@ssi.gouv.fr> wrote: > >> Hi list, >> >> I am sorry for the very late answer concerning draft 18, but we >> (ANSSI) have several remarks after proof-reading the current >> specification. >> >> We are sorry for the multiple long messages. >> >> If the WG is interested by some of our concerns/proposals, we would be >> glad to propose some PRs. >> >> >> = HRR and supported groups cache = >> >> In 4.2.4 (P.41), a server can send a supported_groups extension to >> "update the client's view of its preference" in its ServerHello. >> Since this behaviour is completely left to the client's discretion, it >> does not seem a very relevant policy from the server: either the >> server accepts one of the proposed groups, or it sends an HRR. We do >> not think the middle ground (OK for this group, but I would prefer >> this other one) is relevant, so the sentence should be removed. >> >> Moreover, as far as I could understand, there is no indication in the >> specification that a client should remember the preference of the >> server in case it receives a HRR, which there would definitely make >> sense. Such text could go in 4.1.4. >> >> I can propose a PR for this point. >> >> >> Olivier Levillain >> >> _______________________________________________ >> 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 > > --001a11421478a1672d0541e89928 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2016 at 11:09 AM, Steven Valdez <<= a href=3D"mailto:svaldez@chromium.org" target=3D"_blank">svaldez@chromium.o= rg> wrote:
Being able to send supported_groups does allow a server to choose to make = a tradeoff between an extra round trip on the current connection and its ow= n group preferences. One example where a server might want to do this is wh= ere it believes that X25519 is likely a more future-proof group and would p= refer that, but still believes the client's choice of P256 is suitable = for this connection. Always requiring an extra round trip might end up bein= g expensive depending on the situation so some servers might prefer to avoi= d sending an HRR for a slightly more preferred group.

I = think that requiring the client to maintain state from the supported_groups= puts undue requirements on the client, since not all clients keep state be= tween connections, and those that do usually only keep session state for re= sumption.

This matches my view = as well.

I agree that the client should not be req= uire to keep state. I do not believe that the draft requires this, but if s= omeone thinks otherwise, please send a PR to fix.

= -Ekr
=C2=A0
=

On T= ue, Nov 22, 2016 at 2:01 PM Olivier Levillain <olivier.levillain@ssi.gouv.fr= > wrote:
Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


=3D HRR and supported groups cache =3D

In 4.2.4 (P.41), a server can send a supported_groups extension to
"update the client's view of its preference" in its ServerHel= lo.
Since this behaviour is completely left to the client's discretion, it<= br class=3D"m_-4340906851144926682gmail_msg"> does not seem a very relevant policy from the server: either the
server accepts one of the proposed groups, or it sends an HRR.=C2=A0 We do<= br class=3D"m_-4340906851144926682gmail_msg"> not think the middle ground (OK for this group, but I would prefer
this other one) is relevant, so the sentence should be removed.

Moreover, as far as I could understand, there is no indication in the
specification that a client should remember the preference of the
server in case it receives a HRR, which there would definitely make
sense.=C2=A0 Such text could go in 4.1.4.

I can propose a PR for this point.


Olivier Levillain

_______________________________________________
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


--001a11421478a1672d0541e89928-- From nobody Tue Nov 22 11:24:14 2016 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 3E07C129B4F for ; Tue, 22 Nov 2016 11:24:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 qiQew3wLhcvM for ; Tue, 22 Nov 2016 11:24:11 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 4BCBE129B12 for ; Tue, 22 Nov 2016 11:24:11 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id i145so23150412ywg.2 for ; Tue, 22 Nov 2016 11:24:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=PwY70h1yFZxGFzRLhDh7WTq5LyTgSGZwznIVBMIaSHc=; b=UoNwYqZMMyiKagQRawVHUcebcxtsI7nnWbfBaJsV1zglKbXeT1xfhvOu1GtrMfDDgD +veWbEPpbMBFIRMUXEPBDj14uRljTiCZeo+pm0xGHHannTpjIPeMa0Bar8LxemcyGIcy 7wkMMPVku2/4tlgg5+LaBSzveepLVYLg2Jo4fJi89qzucoBUrP0JETXbXHS4K2Sri1sc BG6EPFRGQ13rNs5we+mCz8LghpMyrSzgm2ZB+5VjdQ30vZcPNr57sk5V+vugq2TPwydy EZZVqDGO8J5p3G0TA1ia0mMmd2DkMYFWxPJl8Pffs5MmtC6YePdS5ZgmNTpUUeMVCrlw GsFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PwY70h1yFZxGFzRLhDh7WTq5LyTgSGZwznIVBMIaSHc=; b=gT907f3GyPegRyIlc0YOSbg+ea4NBuOZuu4DdADrWcebmMv+xUds5wGVo0pySGvagT 9FEYTsTtP1s4lN5kj78DYFAZ9/zTtMnCGSRMUhsZYQ9iDoQ+ujBdJT7MjJmat/GgjTlD ZQieQMvgAYFYdQ22kcnQKVB1PgfqPZZ5bXoTAohzvpYAjjT6HcTK6lifON17PNHoqQGo KiSkxwAoLIn75NVp3MSAAs54kGAlBTHr6/umd26ABy3OW/ksHSRdCxVycy/Yl1PIGF5W wt8J2opAkzbbKV4ZYz5G4DVG5k4TmsGS53KgzmSuBWrElx0D8kbJIcD1R3oadpS4+dX0 hiMg== X-Gm-Message-State: AKaTC03oaQvQvfYqABXamrr4masBmHlZovg/EhDJJDlld1P5NXt+daaRDjLfwe1qi2PedUjS0WJ8+wjhO5AZXg== X-Received: by 10.129.53.194 with SMTP id c185mr22199746ywa.205.1479842650546; Tue, 22 Nov 2016 11:24:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Tue, 22 Nov 2016 11:23:29 -0800 (PST) In-Reply-To: <20161122190651.GD19978@neoplankton.picty.org> References: <20161122190651.GD19978@neoplankton.picty.org> From: Eric Rescorla Date: Tue, 22 Nov 2016 11:23:29 -0800 Message-ID: To: Olivier Levillain Content-Type: multipart/alternative; boundary=001a1142147882b1920541e8b7a7 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : PSK and PSK Binder X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:24:13 -0000 --001a1142147882b1920541e8b7a7 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 22, 2016 at 11:06 AM, Olivier Levillain < olivier.levillain@ssi.gouv.fr> wrote: > Hi list, > > I am sorry for the very late answer concerning draft 18, but we > (ANSSI) have several remarks after proof-reading the current > specification. > > We are sorry for the multiple long messages. > > If the WG is interested by some of our concerns/proposals, we would be > glad to propose some PRs. > > > = PSK and PSK Binder = > > P.35 (4.2), it is specified that the pre_shared_key extension must be > the last extension in the ClientHello, because of the way the PSK > Binder is computed. This seems very hackish and will most certainly > lead to implementation errors. However, I understand that it was not > easy to propose a cleaner mechanism while keeping a common flow > between *DHE and PSK modes. > I agree that this is piece is a little structurally unfortunate. It was a compromise between a number of different imperatives and this ended up being the best. Yet, we would have preferred that PSK would not be MTI as stated in > the end of the document (P.81, section 8.2). In previous versions PSK > and resumption was not MTI, so it might be logical to keep it this > way. Alternatively, we might propose a profile defining a simpler TLS > subset. > I agree with this comment. I don't think the WG ever had consensus to require PSK, it was just a side effect of trying to specify a list of MTI extensions. I have filed https://github.com/tlswg/tls13-spec/issues/771 to keep track of this. Regarding the definition of the PSK Binder (P. 45 and 46, section > 4.2.6.1), we found it very hard to read, since the binding value is > said to be computed as the Finished message, but differently. In > particular, it would be useful to give the relevant information (I > believe the Handshake Context is called transcript in this section, > and it would be important to explicit the Hash to use), instead of > implying it. It would not take much space in the document, but it > would ensure implementers know how to compute the binder. > OK. I will see if I can figure out how to rewrite this to make it clearer. -Ekr > > > Olivier Levillain > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1142147882b1920541e8b7a7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Nov 22, 2016 at 11:06 AM, Olivier Levillain <<= a href=3D"mailto:olivier.levillain@ssi.gouv.fr" target=3D"_blank">olivier.l= evillain@ssi.gouv.fr> wrote:
Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


=3D PSK and PSK Binder =3D

P.35 (4.2), it is specified that the pre_shared_key extension must be
the last extension in the ClientHello, because of the way the PSK
Binder is computed.=C2=A0 This seems very hackish and will most certainly lead to implementation errors.=C2=A0 However, I understand that it was not<= br> easy to propose a cleaner mechanism while keeping a common flow
between *DHE and PSK modes.

I agree tha= t this is piece is a little structurally unfortunate. It was a
co= mpromise between a number of different imperatives and this ended
up being the best.


Yet, we would have preferred that PSK would not be MTI as stated in
the end of the document (P.81, section 8.2).=C2=A0 In previous versions PSK=
and resumption was not MTI, so it might be logical to keep it this
way.=C2=A0 Alternatively, we might propose a profile defining a simpler TLS=
subset.

I agree with this comment. I do= n't think the WG ever had consensus
to require PSK, it was ju= st a side effect of trying to specify a list of
MTI extensions. I= have filed=C2=A0https://github.com/tlswg/tls13-spec/issues/771 to
keep track= of this.


Regarding the definition of the PSK Binder (P. 45 and 46, section
4.2.6.1), we found it very hard to read, since the binding value is
said to be computed as the Finished message, but differently.=C2=A0 In
particular, it would be useful to give the relevant information (I
believe the Handshake Context is called transcript in this section,
and it would be important to explicit the Hash to use), instead of
implying it.=C2=A0 It would not take much space in the document, but it
would ensure implementers know how to compute the binder.
<= div>
OK. I will see if I can figure out how to rewrite this t= o make it clearer.

-Ekr
=C2=A0


Olivier Levillain

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a1142147882b1920541e8b7a7-- From nobody Tue Nov 22 11:28:22 2016 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 8CAD7129B3F for ; Tue, 22 Nov 2016 11:28:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 LVzlw8gRLdGS for ; Tue, 22 Nov 2016 11:28:18 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 E8A201296EA for ; Tue, 22 Nov 2016 11:28:17 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id t125so23133192ywc.1 for ; Tue, 22 Nov 2016 11:28:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kbtojVPbIIbKdZmetIlC/ZPjSmhElVPH9r9d6iOrXy8=; b=EFdCuthky36t7nyZAQpBgWksaythT3OrZ+FYRqdZZbwyBaizOVkstn6w9kO+4BHFhS cJLMmMEeEql/FEw/G95yn168BvkMmg21tcuZVOPEgN5caVLUb3XnkbykIWW8laROIn17 RSXIn5gTXojNHgpkAfmxdI4H6in1AH5eFiZwGzlhoLyauukLgBh4M5OA4+d7be3fdw1L 5liTlI8IfQKS38+pyKMCTCeZkUSF3Pw2RYkyVJydh5LfabHv8O/4SXANPtCoUuhuejTz 7BEuY4jUYlFF4/9OuS5ht3BOAzDKObc0LAy/0Q8TrdiEZ8pxs8HRoiPDEsVYFFyn4A7V VB9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kbtojVPbIIbKdZmetIlC/ZPjSmhElVPH9r9d6iOrXy8=; b=dktwR088DiWOiQb7y/EjfPQuNDVJjdeuSNckZFFczYVe0z6ErSu30Qk9yh5g+0Obwj AOlJ695MUjYJKjfMmV43sBFvt8KCg+HBXwCNoTpKPMl2Nl3hNm+A3ge7RZGt7h+WV9Dn ABcEV0kn+VEPkXqPV7maf506NlTaav56eOqYCJrMIS+eWgi8jhgu9aaw1wgeDAg4pFsB Agjx11zYvE4ZMaA8OpRxn5wA2RNyLLQbn3FXeSnsGTJmdPmawAxvA+ZSzGK7U4pikOch eYF5LzYi6ZtP2GvbXxNGC1qVY0Eh7oF9uo7XK1CxuAfgdZdaOBlQ+aZ/CY4o1pOkHhvd fDwg== X-Gm-Message-State: AKaTC012mCeKQxwuJ+mQUIDOcyA/R52xMngsvawQptMQs8Tqs/cJJZt0OKMLoGWrPRNGhwHh8GU61YZ2bC7kZw== X-Received: by 10.129.108.216 with SMTP id h207mr22577247ywc.52.1479842897187; Tue, 22 Nov 2016 11:28:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Tue, 22 Nov 2016 11:27:36 -0800 (PST) In-Reply-To: <20161122190738.GF19978@neoplankton.picty.org> References: <20161122190738.GF19978@neoplankton.picty.org> From: Eric Rescorla Date: Tue, 22 Nov 2016 11:27:36 -0800 Message-ID: To: Olivier Levillain Content-Type: multipart/alternative; boundary=001a114dd36e361e8d0541e8c6f5 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Signature in certificates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:28:20 -0000 --001a114dd36e361e8d0541e8c6f5 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 22, 2016 at 11:07 AM, Olivier Levillain < olivier.levillain@ssi.gouv.fr> wrote: > Hi list, > > I am sorry for the very late answer concerning draft 18, but we > (ANSSI) have several remarks after proof-reading the current > specification. > > We are sorry for the multiple long messages. > > If the WG is interested by some of our concerns/proposals, we would be > glad to propose some PRs. > > > = Signature in certificates = > > The two paragraphs in 4.4.1.2 P.56 starting with "All certificates" > are very far from clear. They require (MUST) some behaviour, which is > later reformulated with an unless part. I am not sure of the intent > here, but we believe the current text should be rewritten to clearly > express the intent of the WG. > We did try to make this clear, but maybe we failed. My comprehension is that the server MUST use only signature schemes > described in signature_algorithms, except for the following cases: > - for checking the signature in self-signed or trust anchors (since > this check is useless, the trust coming from an out-of-band > mechanism in this case) > - when the only available chains use signature scheme are not known > to be supported by the client > - the case of SHA-1 is special > Yes, this seems accurate. If you would like to provide a PR that you think makes this clearer, that would be appreciated. -Ekr > The same confusion can be found in 4.4.2 P.59 ("If sent by a > server...") > > > Olivier Levillain > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dd36e361e8d0541e8c6f5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2016 at 11:07 AM, Olivier Levillain &= lt;olivi= er.levillain@ssi.gouv.fr> wrote:
Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


=3D Signature in certificates =3D

The two paragraphs in 4.4.1.2 P.56 starting with "All certificates&quo= t;
are very far from clear.=C2=A0 They require (MUST) some behaviour, which is=
later reformulated with an unless part.=C2=A0 I am not sure of the intent here, but we believe the current text should be rewritten to clearly
express the intent of the WG.

We did tr= y to make this clear, but maybe we failed.


My comprehension is that the server MUST use only signature schemes
described in signature_algorithms, except for the following cases:
=C2=A0- for checking the signature in self-signed or trust anchors (since =C2=A0 =C2=A0this check is useless, the trust coming from an out-of-band =C2=A0 =C2=A0mechanism in this case)
=C2=A0- when the only available chains use signature scheme are not known =C2=A0 =C2=A0to be supported by the client
=C2=A0- the case of SHA-1 is special

Ye= s, this seems accurate. If you would like to provide a PR that you think ma= kes this
clearer, that would be appreciated.

=
-Ekr


The same confusion can be found in 4.4.2 P.59 ("If sent by a
server...")


Olivier Levillain

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114dd36e361e8d0541e8c6f5-- From nobody Tue Nov 22 11:31:36 2016 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 8F792129B46 for ; Tue, 22 Nov 2016 11:31:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 LlAu2iv_AgX9 for ; Tue, 22 Nov 2016 11:31:32 -0800 (PST) Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 43F311294AA for ; Tue, 22 Nov 2016 11:26:00 -0800 (PST) Received: by mail-yw0-x235.google.com with SMTP id a10so23020083ywa.3 for ; Tue, 22 Nov 2016 11:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tLMzN/eUvg7+UyJMch6vEAhW2TRwwXvfEiqSVJ2AWZk=; b=NNViIX3BUxr9SOG/sO+ETx+jFVVfPDf6+2bbYGGzIjEZpHP+2OHCe3S0q7R7H6B7vE fsgFNOb02mKKS/YOVZNhcf1FZRSdbvB8azCmf40qi9LJyY73y6VHFksMqBNO6T4mir1J NyXq+a6Tp7J6Xu6BDkBdUbHFejlqdyEE0+mPFMfxkL84f0/myXDJKD8mGF6lM88/5Z6C YbW2jxtA/INR9uV9UC64Jq9XtxTS622gvJHieCYnpEptBllBKsD0FeLerxi49mvG+l+X yY9yta2ADCKiE4Byv/qs/HFI9+lMSEjeqj1M9RCWoEyR7lpw4U8JcH6+42YWsTIcLdaC D5wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tLMzN/eUvg7+UyJMch6vEAhW2TRwwXvfEiqSVJ2AWZk=; b=JtnSJgj9Da48hJVnxihC2A3MPDAwyTEB8cZ4z8Uv00L0a0cjlEYNVzYYtX3U7Wnx9a jHeq55SoS3/XJtZ7S5vfzaVxrMo6p7O5KTZfknP40M4ESUzEPAxbKk2LZDxLuyaHLIVv mFwgk1u4GaYGXJq6Q5HMIbQ1UlX/t46Zbraijc/8nXsTS+kIg3iNc6on+yWBKG2IpvIo lUzFniX0LWPa1GdObN412Ujh7bSQbGDjLqqqEMBFAGmQ6fRVMcrxhT42Nzxgxv3OaWSU QwYxK1fPw+vVVoHOavtazusnIMb1mOBif/Wkh+7Et+1UrS7VsqfaTODj7eIpmY+U1XVR wWMA== X-Gm-Message-State: AKaTC00U6Nw9gTQPjM4170xmCEPhKkqjpu0vM6Cn0AAxhM9/d3rJXwTKNeoXDYbuUV2LHxcf2lXamYQyp793uQ== X-Received: by 10.129.121.1 with SMTP id u1mr21480262ywc.146.1479842759560; Tue, 22 Nov 2016 11:25:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Tue, 22 Nov 2016 11:25:19 -0800 (PST) In-Reply-To: <20161122190758.GG19978@neoplankton.picty.org> References: <20161122190758.GG19978@neoplankton.picty.org> From: Eric Rescorla Date: Tue, 22 Nov 2016 11:25:19 -0800 Message-ID: To: Olivier Levillain Content-Type: multipart/alternative; boundary=94eb2c0a8f8201ff4e0541e8bec1 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Message order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 19:31:34 -0000 --94eb2c0a8f8201ff4e0541e8bec1 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 22, 2016 at 11:08 AM, Olivier Levillain < olivier.levillain@ssi.gouv.fr> wrote: > > = Message order = > > I believe the message P.27 section 4 is important, but not > sufficient. As already expressed on the list, a formal automaton > should be provided in the spec. > > I think Ekr said there was some work in progress in this area. Is > this a goal for the final specification? > Yes, I will put some sort of more complete state machine in the final spec (probably in -19) -Ekr > > Olivier Levillain > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0a8f8201ff4e0541e8bec1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

= On Tue, Nov 22, 2016 at 11:08 AM, Olivier Levillain <<= a href=3D"mailto:olivier.levillain@ssi.gouv.fr" target=3D"_blank">olivier.l= evillain@ssi.gouv.fr> wrote:


Olivier Levillain

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--94eb2c0a8f8201ff4e0541e8bec1-- From nobody Tue Nov 22 13:19:56 2016 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 EF827129576 for ; Tue, 22 Nov 2016 13:19:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 lFhNj47CoXJj for ; Tue, 22 Nov 2016 13:19:52 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 82BE912941C for ; Tue, 22 Nov 2016 13:19:52 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id t125so25640342ywc.1 for ; Tue, 22 Nov 2016 13:19:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=d9p5XA1gjPKwwsaCLXWwu+JliU2W48EdSGzhSUhSjNI=; b=THsN7j3FQ0E/JITYY69giUiH9cFNiGj6pYmvGWn+4t5ZEucgiqaG85H6z0K/+FCrUv gkbc5GnPBZZGMY9g5PeDLQarH+Sk1vZIyMu14tGHbZIgOPHo5EGtQmETyQ8w9b4Xha4j VwK7hwgPOF5MAwoBIs9+XvCVVgdTc8HXv6VHoksaFRraTB7QKww8kuA9Ae2SEX+g+gz+ rzRbY0jNsq9dqfV5HNHZugiamvYltgwf8jp0Gshl+vqa7Pin9SGfDze9TgBkcmU5/hsb 5uFhFNml5ZMdGDrbop78tI/r+UF85uIM+M9pxpUozs3yjAyILVsTA/BUlsxKaWq29t3j ZX0Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=d9p5XA1gjPKwwsaCLXWwu+JliU2W48EdSGzhSUhSjNI=; b=QU+nSjctCeJdsQYP9kEL+8nLtoM25opo8bqA2kPShXmrZ3H0lWRQqe24+oL3IApMAG mwEk1GmsGOazhJh4eLvclwZA/4DyuBdFlXT7r0McPdridHVZXp+o8RO5Y6AixQ3g3yRE vraCx9gUzGBTOgnY7VWkflNDzXrG6ya6vluY0dOVwJJUb0XPl4qMWJBVZ9kDeyZ5ha9N iHqfhvODHHJWU0k82QbxOrlUpgwUv9ZuPhzaRHzHqPep17rjbAzw0p4GvA/gbRvbrKt9 igeWQtEdI+tK+dToOYrg14bjYkrTQX+OnOGZqrsFdzej7rDT1BAUMJTk0GxdptrxhgBg J58Q== X-Gm-Message-State: AKaTC01/pPLRm+2UCpOL+NOXjwvSUS3dmNDpdzUB9skcym/2lnWzCuc40cjrAiORu5AnfqYKpyIXw85rONlCcw== X-Received: by 10.129.108.216 with SMTP id h207mr23183791ywc.52.1479849591759; Tue, 22 Nov 2016 13:19:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Tue, 22 Nov 2016 13:19:11 -0800 (PST) In-Reply-To: <20161122190158.GB19978@neoplankton.picty.org> References: <20161122190158.GB19978@neoplankton.picty.org> From: Eric Rescorla Date: Tue, 22 Nov 2016 13:19:11 -0800 Message-ID: To: Olivier Levillain Content-Type: multipart/alternative; boundary=001a114dd36e3d5bf50541ea55fb Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Extensions and message reuse X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 21:19:55 -0000 --001a114dd36e3d5bf50541ea55fb Content-Type: text/plain; charset=UTF-8 On Tue, Nov 22, 2016 at 11:02 AM, Olivier Levillain < olivier.levillain@ssi.gouv.fr> wrote: > > = Extensions and message reuse = > > We were sorry to find that some TLS 1.2 extensions were reused with a > different meaning, or that some TLS 1.3 extensions were context > dependent, which does not allow for a clear separation between the > parsing step (which might lead to a decode_error alert) and the > message validation step (which might lead to an invalid_parameter > alert). It is especially disappointing since the choice made for the > ciphersuites is a very clean one. > > The first example of such a problem is the signature_scheme and > signature_algorithms enums. In practice, the signature_algorithm must > contain information valid for TLS 1.2 and TLS 1.3, but the exact > meaning is not the same in both cases. It would be cleaner to have a > new, separate extension called signature_scheme, defining the new > enum. This way, a TLS 1.2/1.3 client implementations would send both > extensions. We would spend 10 bytes on the wire, but it is not that > important for the first message which can be kept reasonably long > (and which is sometimes padded via the corresponding extension...) > We certainly could do this, but I don't think it's the right answer, for two reasons: 1. From a protocol perspective, some of the things you could say with signature_algorithms weren't coherent. For instance: I support ECDSA_SHA512 but only with P256 (via supported_curves). So it's actually a retroactive improvement to TLS 1.2 to use the code points this way. NSS, at least interprets these the same way in TLS 1.2 and TLS 1.3. I believe BoringSSL does as well. 2. From an implementation perspective, it's easier to just have a single external facing surface, which should be the more sensible one, namely signature schemes. > Another example is the key_share extension: it is in fact made of > three different extensions, depending on the message where it is > included. It would be simpler for a (almost-)stateless parser* to > either use three different extensions or to use the same content each > time. In the second case, the extension would each time consist of a > list of (group + optional keyshare). The advantages of such a unified > keyshare extension would be: > - stateless parsing* > - no reuse of supported_groups which can be merged with key_share > - no more validation complexity since higher-level checks were > already required (the groups sent by HRR did not came with a key > share for example). > The major con one might see is that the server can not advertise its > supported groups in an encrypted manner anymore (since > supported_groups is not used anymore). However, we do believe > simplifying the implementation is worth it. > > * Of course the parser still has to use the extension id to know how > to parse the value, but it would not need to have broader context > (the message where the extension is included). In other words, we > would like select syntax in structs to only use local information. > > I can try and propose a PR for each extension if there is an interest > in the WG. > It seems to me you are making two points here: 1. That it would be good to unify supported_groups and key_share 2. That we should use separate code points wherever extensions differ between the messages they appear (this is far from the only one). We've had some conversation about the first approach, which seems like kind of a stylistic/taste issue whether to have the "I can do" and "here is" in one place or two, and on balance I think it's better to not change this at this point without a really compelling reason. I can see the appeal of having one parser per extension ID, but it isn't actually that much easier from an implementation perspective. You already need a mapping table from extension ID to handler and that table also needs to be able to detect common problems (e.g., extension reuse or extensions appearing in the wrong place) and it's not hard at that point to also have it point to message-specific parsers (this is how NSS mostly works). ISTM that the alternative you propose would either result in a proliferation of extensions (which confuses the matching rules) or having extensions which are syntactically valid but not legal in their context (e.g., >1 key share from the server). This pushes these checks further away from the decoder, and makes things which would otherwise be syntax errors (e.g., a "pre_shared_key" extension from the server which contains keys) into semantic errors which require explicit checks. -Ekr > > Olivier Levillain > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dd36e3d5bf50541ea55fb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Nov 22, 2016 at 11:02 AM, Olivier Levillain <olivier.levil= lain@ssi.gouv.fr> wrote:
=3D Extensions and message reuse =3D

We were sorry to find that some TLS 1.2 extensions were reused with a
different meaning, or that some TLS 1.3 extensions were context
dependent, which does not allow for a clear separation between the
parsing step (which might lead to a decode_error alert) and the
message validation step (which might lead to an invalid_parameter
alert).=C2=A0 It is especially disappointing since the choice made for the<= br> ciphersuites is a very clean one.

The first example of such a problem is the signature_scheme and
signature_algorithms enums.=C2=A0 In practice, the signature_algorithm must=
contain information valid for TLS 1.2 and TLS 1.3, but the exact
meaning is not the same in both cases.=C2=A0 It would be cleaner to have a<= br> new, separate extension called signature_scheme, defining the new
enum.=C2=A0 This way, a TLS 1.2/1.3 client implementations would send both<= br> extensions.=C2=A0 We would spend 10 bytes on the wire, but it is not that important for the first message which can be kept reasonably long
(and which is sometimes padded via the corresponding extension...)

We certainly could do this, but I don't thi= nk it's the right answer, for
two reasons:

1. From a protocol perspective, some of the things you could say wit= h
signature_algorithms weren't coherent. For instance: I supp= ort ECDSA_SHA512
but only with P256 (via supported_curves). So it= 's actually a retroactive
improvement to TLS 1.2 to use the c= ode points this way. NSS, at least
interprets these the same way = in TLS 1.2 and TLS 1.3. I believe BoringSSL
does as well.

2. From an implementation perspective, it's easier to= just have a single
external facing surface, which should be the = more sensible one, namely
signature schemes.

=


=C2=A0
Another example is the key_share extension: it is in = fact made of
three different extensions, depending on the message where it is
included.=C2=A0 It would be simpler for a (almost-)stateless parser* to
either use three different extensions or to use the same content each
time.=C2=A0 In the second case, the extension would each time consist of a<= br> list of (group + optional keyshare).=C2=A0 The advantages of such a unified=
keyshare extension would be:
=C2=A0- stateless parsing*
=C2=A0- no reuse of supported_groups which can be merged with key_share
=C2=A0- no more validation complexity since higher-level checks were
=C2=A0 =C2=A0already required (the groups sent by HRR did not came with a k= ey
=C2=A0 =C2=A0share for example).
The major con one might see is that the server can not advertise its
supported groups in an encrypted manner anymore (since
supported_groups is not used anymore).=C2=A0 However, we do believe
simplifying the implementation is worth it.

* Of course the parser still has to use the extension id to know how
=C2=A0 to parse the value, but it would not need to have broader context =C2=A0 (the message where the extension is included).=C2=A0 In other words,= we
=C2=A0 would like select syntax in structs to only use local information.
I can try and propose a PR for each extension if there is an interest
in the WG.

It seems to me you are makin= g two points here:

1. That it would be good to uni= fy supported_groups and key_share
2. That we should use separate = code points wherever extensions differ
between the messages they = appear (this is far from the only one).

We've = had some conversation about the first approach, which seems like kind
=
of a stylistic/taste issue whether to have the "I can do" an= d "here is" in one
place or two, and on balance I think= it's better to not change this at this point
without a reall= y compelling reason.

I can see the appeal of havin= g one parser per extension ID, but it isn't
actually that muc= h easier from an implementation perspective. You already
need a m= apping table from extension ID to handler and that table
also nee= ds to be able to detect common problems (e.g., extension reuse
or= extensions appearing in the wrong place) and it's not hard at that
point to also have it point to message-specific parsers (this is how= NSS
mostly works). ISTM that the alternative you propose would e= ither result
in a proliferation of extensions (which confuses the= matching rules)
or having extensions which are syntactically val= id but not legal in
their context (e.g., >1 key share from the= server). This pushes these
checks further away from the decoder,= and makes things which would
otherwise be syntax errors (e.g., a= "pre_shared_key" extension from
the server which conta= ins keys) into semantic errors which require
explicit checks.

-Ekr



Olivier Levillain

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114dd36e3d5bf50541ea55fb-- From nobody Tue Nov 22 14:06:58 2016 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 07F1C1296C0 for ; Tue, 22 Nov 2016 14:06:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k6BZyGQMrjvA for ; Tue, 22 Nov 2016 14:06:54 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (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 8C90B129560 for ; Tue, 22 Nov 2016 14:06:53 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id n21so44892944qka.3 for ; Tue, 22 Nov 2016 14:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=K5SOvmEeAwhGPKb5mjBP4tiWJqU3Brpp/qUw1nEoUAQ=; b=mmk224dOMtlecGV+6TRGapwPpHum1hnsTiFXUIhD2DGtO+xbuPC/VTMyv3aIvRgDRt ay5y2hpmfkGc+qyHQWScOQlle58xDpQODnTOkHCkkVKnaN836pdngwp+CV+/jrakrQ+X WR8KsMptoDUHjWsZH3TW78mrRAtqL6VgDsQoY2Dne8v85cFZ3eP7ujZCiGbQWnUqGnL4 gcNn+jIzgGtUZiTnOFqsEP/YD23VdmH25LOxq2qLgALmjDw6IR1hI3xhlNcOCoY8q06T 74RLhcOec/Qn3Bg1x8UK13vERTwIDoSw+YiAWMIcDseasTM+cjhbnIUN8tVNp0qPFEyp o/YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=K5SOvmEeAwhGPKb5mjBP4tiWJqU3Brpp/qUw1nEoUAQ=; b=PU0XnAoQRLbzpUSOskLugYP/Fwmif1Di3usb2gwFUQFIU6ttJ4yOdIZZYP4OMBXvR4 IgF0g9RItXhyijAjw/sM1f7DgifhFstGX/aLX/H/Pf3pW4sam0EzH2f6VKdCZ+DaGKeB FzeMsKBRophOwg5XJC3GDIVxmsibjWIhNBc4aanFJsBDLN2mGQ7PAH4Fe2He1QqWNmC1 dsDWEgzgY7P1XTGnycmG1TvVo4AqkEyZKKkpSZ5ZjFZqKOgey/7FELNKsMNOW60ij0FS P/jXHZMhZ75cFDtKwMc1d1+MLNyY+pRP4fXRx9vf9nrQA9y0efrU6W/HdOnHgqonpUO5 D9jw== X-Gm-Message-State: AKaTC0125H6zSaPqn8eGobnNSFTVMUF7RAG3bz9eSfbPBXqiQHI2IsN3nQCK+UKrtcexDg== X-Received: by 10.55.0.65 with SMTP id 62mr24359329qka.106.1479852412684; Tue, 22 Nov 2016 14:06:52 -0800 (PST) Received: from dave-laptop.localnet (pool-71-175-27-43.phlapa.fios.verizon.net. [71.175.27.43]) by smtp.gmail.com with ESMTPSA id g97sm4990272qkh.11.2016.11.22.14.06.51 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 22 Nov 2016 14:06:51 -0800 (PST) From: Dave Garrett To: tls@ietf.org Date: Tue, 22 Nov 2016 17:06:50 -0500 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <201611221706.50692.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 22:06:56 -0000 (replies to a bunch of ideas in this thread) As the person who lit the match under this latest bikeshed debate, personally, I don't see a strong consensus building here. Leaving the bikeshed unpainted seems like the option we're headed for, at this rate. I'm fine with TLS 1.3 if that's the result here. That said, I think I've been somewhat swayed to the TLS 4 camp with the "fourth version of TLS" message. It makes a kind of messy sense that's kind of fitting for TLS. I'm no longer against it. I've also suggested highlighting the year in the past, but only in the context of the title and messaging, not actually replacing the version number itself. I'd be ok with TLS 1.3-2017 (or something), not doing a find/replace of 1.3 and changing it to 2017, wholesale. That just feels even more confusing. Lastly, I am vehemently against the suggestion of ditching the TLS name in favor of SSL again, as was also brought up in this thread. SSL is dead and insecure, and that message needs to stay. We need to get people to stop conflating the two and making this worse, not accepting it. Dave On Sunday, November 20, 2016 08:16:07 pm Eric Rescorla wrote: > I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we're going to rev the major > version number we should abandon the minor one). > TLS 2017 strikes me as quite bad; we're certainly not planning to do a TLS > 2018. I am strongly opposed to TLS 2017. > > -Ekr > > > On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner wrote: > > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > > rebrand TLS1.3 to something else. Slides can be found @ > > https://www.ietf.org/proceedings/97/slides/slides- > > 97-tls-rebranding-aka-pr612-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > > on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. From nobody Tue Nov 22 14:18:42 2016 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 CA3D81295F4 for ; Tue, 22 Nov 2016 14:18:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.196 X-Spam-Level: X-Spam-Status: No, score=-4.196 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org 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 do7iBEung104 for ; Tue, 22 Nov 2016 14:18:39 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (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 ADEF512949D for ; Tue, 22 Nov 2016 14:18:39 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id q130so45380647qke.1 for ; Tue, 22 Nov 2016 14:18:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=KWBG+ETLCsELBkOukSLqmbWfLD+FBVq9gzNFWUW9Piw=; b=PZHG9Fjf4hRjVivmfxKxkfCJm5f5IGP8QRh7AmmlxkwhR60n5fxdScwXhrnudVK4GN UNKwhudvO+s+vzXC0l/IZR0FXUKwN6yUE1GRTz9RIjlKdHAPCv3G6xeEfOaDEh5m8FoU ZC1XrRTNS4c4eyK10oMb0SngVrVYbEjJk6cGA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=KWBG+ETLCsELBkOukSLqmbWfLD+FBVq9gzNFWUW9Piw=; b=GxWy8/IS7vmPjwXHvD4luMf4CP69duIymF1/zLgrPRAbrgWx/uR0tD3MX5Fb+AvgvM U4tSZVUwdavpe/lHxGWvSq0fWlYRgWFyWEKqlfYn52r626y6/DDvaMGpfaOApXsf7a1I h+fXWx7NDsrHSbudTjQ8AJfaqb71NcWaM0Z0CqPKv/TCW+VkPFcCPvckdAJq+U+Dg8gm FxtSv58hHI3EruQFFgOeSm5st07bVX0hzmEbrAk+H79fLRg9kiZckaXKB5YgBuxvSFc+ HP60aP0r/kH3fV2+8i0wfSw/SEbAoMoqatwL0I2sHgA943ponOI4OWNf2o3defiW5lF/ cWLw== X-Gm-Message-State: AKaTC02xYiKzBh9//8HUz31Ou184ihfoHf4VbJ9V4P7VeO8QHWZG2s2FBdHG06VW2V6XmwbuItfz4BWEO6ecBQ49 X-Received: by 10.55.122.134 with SMTP id v128mr23087094qkc.111.1479853117819; Tue, 22 Nov 2016 14:18:37 -0800 (PST) MIME-Version: 1.0 References: <20161122190822.GH19978@neoplankton.picty.org> In-Reply-To: <20161122190822.GH19978@neoplankton.picty.org> From: David Benjamin Date: Tue, 22 Nov 2016 22:18:27 +0000 Message-ID: To: Olivier Levillain , tls@ietf.org Content-Type: multipart/alternative; boundary=94eb2c062a5868ae8c0541eb27fa Archived-At: Subject: Re: [TLS] Draft 18 review : Message splitting and interleaving X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 22:18:42 -0000 --94eb2c062a5868ae8c0541eb27fa Content-Type: text/plain; charset=UTF-8 On Tue, Nov 22, 2016 at 2:05 PM Olivier Levillain < olivier.levillain@ssi.gouv.fr> wrote: > Hi list, > > I am sorry for the very late answer concerning draft 18, but we > (ANSSI) have several remarks after proof-reading the current > specification. > > We are sorry for the multiple long messages. > > If the WG is interested by some of our concerns/proposals, we would be > glad to propose some PRs. > > > = Message splitting and interleaving = > > How to split and interleave subprotocols in TLS has not been clearly > specified in the past, and it would be useful to be crystal clear on > this point. > > In the specification, the subject is first presented in 4.5 (P.61): > Handshake messages sent after the handshake MUST NOT be interleaved > with other record types. That is, if a message is split over two or > more handshake records, there MUST NOT be any other records between > them. > But I am wondering why this text only concern "messages after the > handshake". It should always be the case! > > It is next present in section 4.5.3 (P.64): > Handshake messages MUST NOT span key changes. Because the > ServerHello, Finished, and KeyUpdate messages signal a key change, > upon receiving these messages a receiver MUST verify that the end of > these messages aligns with a record boundary; if not, then it MUST > terminate the connection with an "unexpected_message" alert. > > And then in section 5 (mostly P.64 and P.65) plus a repetition P.69. > > > It is worth noting that this specific point was (at least partially) > the origin of several security issues: > - the alert attack (https://www.mitls.org/pages/attacks/Alert); > - Heartbleed (where OpenSSL answered with a fragmented record whereas > it was not the spirit of the spec); > - the OpenSSL Downgrade attack in 2014. > > Some of this is covered in the current specification, but it might be > worth being even stricter: > - regarding splitting/merging, they should be forbidden by default; > - the default would apply to alerts (currently, the spec states that > alerts MUST not be split, but they should not be merged either > for simplicity's sake and since it is useless); > +1. We (BoringSSL) and I believe NSS already forbid this for alerts at all versions. This rule is actually implied by TLS 1.3 already, because we've gotten rid of warning alerts. All alerts terminate the connection, except for end_of_early_data, and end_of_early_data immediately signals a key change. So it is not legal to send two alerts in the same epoch, much less in the same record. (Being explicit about this is good, of course.) > - incidentally, the default behaviour would apply to Heartbeat, as > was the intent of the specification; > - ApplicationData should be considered as a stream with possibly > 0-length records > - Handshake messages should either come as a sequence of multiple > *entire* messages, or as a fraction of *one* message. That is, > the number of HS messages inside one record should either be a > round number or strictly less than 1. > What simplifications were you expecting out of this? It seems to me this would be a nuisance to both enforce as a receiver and honor as a sender. Our implementation doesn't try to pack handshake messages into records, but I believe NSS does. NSS folks should confirm, but I expect such implementations just buffer the messages up and flush when the buffer exceeds the records size. That means all kinds of splits are plausible: [EncryptedExtensions Certifi] [cateRequest Certificate Cer] [tificateVerify Finished] I share your dislike of the way handshake messages and record boundaries interact (or, rather, don't), but I'm not sure how this rule helps. > These constraints can be expressed in 5.1 and cover most of the > problematic cases. They are easy to check and to enforce. > > > However, the problem of the OpenSSL Downgrade flaw (where the first > record containing the beginning of the ClientHello was cut before the > ClientHello.version field) will still stand, but there is no simple > way to fix this, since version negotiation can now happen anywhere in > the ClientHello extensions, so it might be impossible to enforce that > the client versions are sent in the first record. > > I might volunteer some text if there is an interest of the WG. > > > Olivier Levillain > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c062a5868ae8c0541eb27fa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Nov 22= , 2016 at 2:05 PM Olivier Levillain <olivier.levillain@ssi.gouv.fr> wrote:
Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


=3D Message splitting and interleaving =3D

How to split and interleave subprotocols in TLS has not been clearly
specified in the past, and it would be useful to be crystal clear on
this point.

In the specification, the subject is first presented in 4.5 (P.61):
=C2=A0 =C2=A0Handshake messages sent after the handshake MUST NOT be interl= eaved
=C2=A0 =C2=A0with other record types.=C2=A0 That is, if a message is split = over two or
=C2=A0 =C2=A0more handshake records, there MUST NOT be any other records be= tween
=C2=A0 =C2=A0them.
But I am wondering why this text only concern "messages after the
handshake".=C2=A0 It should always be the case!

It is next present in section 4.5.3 (P.64):
=C2=A0 =C2=A0Handshake messages MUST NOT span key changes.=C2=A0 Because th= e
=C2=A0 =C2=A0ServerHello, Finished, and KeyUpdate messages signal a key cha= nge,
=C2=A0 =C2=A0upon receiving these messages a receiver MUST verify that the = end of
=C2=A0 =C2=A0these messages aligns with a record boundary; if not, then it = MUST
=C2=A0 =C2=A0terminate the connection with an "unexpected_message"= ; alert.

And then in section 5 (mostly P.64 and P.65) plus a repetition P.69.


It is worth noting that this specific point was (at least partially)
the origin of several security issues:
=C2=A0- the alert attack (https://www.m= itls.org/pages/attacks/Alert);
=C2=A0- Heartbleed (where OpenSSL answered with a fragmented record whereas=
=C2=A0 =C2=A0it was not the spirit of the spec);
=C2=A0- the OpenSSL Downgrade attack in 2014.

Some of this is covered in the current specification, but it might be
worth being even stricter:
=C2=A0- regarding splitting/merging, they should be forbidden by default; =C2=A0- the default would apply to alerts (currently, the spec states that<= br class=3D"gmail_msg"> =C2=A0 =C2=A0alerts MUST not be split, but they should not be merged either=
=C2=A0 =C2=A0for simplicity's sake and since it is useless);

+1. We (BoringSSL) and I be= lieve NSS already forbid this for alerts at all versions.

This rule is actually implied by TLS 1.3 already, because we've= gotten rid of warning alerts. All alerts terminate the connection, except = for end_of_early_data, and end_of_early_data immediately signals a key chan= ge. So it is not legal to send two alerts in the same epoch, much less in t= he same record. (Being explicit about this is good, of course.)
= =C2=A0
=C2=A0- incidentally, the default behaviour would apply to Heartbeat, as =C2=A0 =C2=A0was the intent of the specification;
=C2=A0- ApplicationData should be considered as a stream with possibly
=C2=A0 =C2=A00-length records
=C2=A0- Handshake messages should either come as a sequence of multiple
=C2=A0 =C2=A0*entire* messages, or as a fraction of *one* message.=C2=A0 Th= at is,
=C2=A0 =C2=A0the number of HS messages inside one record should either be a=
=C2=A0 =C2=A0round number or strictly less than 1.
<= /blockquote>

What simplifications were you expecting out= of this? It seems to me this would be a nuisance to both enforce as a rece= iver and honor as a sender.

Our implementation doe= sn't try to pack handshake messages into records, but I believe NSS doe= s. NSS folks should confirm, but I expect such implementations just buffer = the messages up and flush when the buffer exceeds the records size. That me= ans all kinds of splits are plausible:

=C2=A0 [Enc= ryptedExtensions Certifi]
=C2=A0 [cateRequest Certificate Cer]
=C2=A0 [tificateVerify Finished]

I share y= our dislike of the way handshake messages and record boundaries interact (o= r, rather, don't), but I'm not sure how this rule helps.
= =C2=A0
These constraints can be expressed in 5.1 and cover most of the
problematic cases.=C2=A0 They are easy to check and to enforce.


However, the problem of the OpenSSL Downgrade flaw (where the first
record containing the beginning of the ClientHello was cut before the
ClientHello.version field) will still stand, but there is no simple
way to fix this, since version negotiation can now happen anywhere in
the ClientHello extensions, so it might be impossible to enforce that
the client versions are sent in the first record.

I might volunteer some text if there is an interest of the WG.


Olivier Levillain

_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--94eb2c062a5868ae8c0541eb27fa-- From nobody Tue Nov 22 15:24:50 2016 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 431FB1297A8 for ; Tue, 22 Nov 2016 15:24:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Ti1iDE2aj7uI for ; Tue, 22 Nov 2016 15:24:47 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 AA02112961F for ; Tue, 22 Nov 2016 15:24:45 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id r204so28121027ywb.0 for ; Tue, 22 Nov 2016 15:24:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=dGlY9WYq2HyCgzuSOCT+L+oIJFyiWenFSbCEWk6tLxg=; b=JeYjGUEQH14N+wLBH2LWgzvjohZ3tGvBrEzxvKf2bJoB+c8GO7NukQnLIXX0VOeau+ 03A4RXWXkELNbwZIWYImpGWNyOMaU/9i/lhnT4rnqzYAo0ub1SDP3kwR9LlvpX6Bsoi8 aXrCh4Jv5a6Ti6jC8C+KivBzELmeHBIXN7pH6cBLn4fpQc4x6BPZsAQNZ5Dm4xDr7bY6 9zpoLq8Q1ru8JNLrDidgsn7dPgJlrYhCCDTvMQaP4Z4LhHGLZkVS5Gp8eJqe/985pFZD Q+n2Tf8QdBhDYAzyXMRXGdksX8Ue21uVXiLfpiU2J8LlyEG+GIc7zkOFs3sptthuytiU W8HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=dGlY9WYq2HyCgzuSOCT+L+oIJFyiWenFSbCEWk6tLxg=; b=XQt4/yvXb5qQ2Zm5T1ktMp2SFFFvqdsxYz5WKeuKVoMx6ZWv9obLhqKKlyWyloEbN9 9bNM4BHcCUu7qfZ+EGnvBLsVFvHnEwThNGtI9OevaXhBqYFPmnNm8ozXDNX6eJdokful SAS3WcoaIuTY+u8sNub3KsjUoeFc2I3teXuwOsay44EOtUy2pJDve3/c3Vdgy6zl2qhr rpg2T52PwM1fIB3VOG5U6R6qQL+e2nWNwAqOFgcKIzSlzVUtiQfY5YfHGq6pppihiRuq +lYlc0K0HtfiqeSBkE+D2Lk8w+pwK/rkoG51w7MwCaPMFAU7/4TbODUwjicORMjsWCLi Wz/g== X-Gm-Message-State: AKaTC01++QvauF3A3Gh4gJT7dYIBpP6fmX2r9vW7Z1J3dFHzNBDB8KKpQpd+ZEgMIaoAFL6BQXW7eaMchVlCtA== X-Received: by 10.129.78.71 with SMTP id c68mr160047ywb.21.1479857084962; Tue, 22 Nov 2016 15:24:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Tue, 22 Nov 2016 15:24:04 -0800 (PST) In-Reply-To: References: <20161122190822.GH19978@neoplankton.picty.org> From: Eric Rescorla Date: Tue, 22 Nov 2016 15:24:04 -0800 Message-ID: To: David Benjamin Content-Type: multipart/alternative; boundary=001a114dac9cde5ffa0541ec13b9 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Message splitting and interleaving X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 22 Nov 2016 23:24:49 -0000 --001a114dac9cde5ffa0541ec13b9 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 22, 2016 at 2:18 PM, David Benjamin wrote: > On Tue, Nov 22, 2016 at 2:05 PM Olivier Levillain < > olivier.levillain@ssi.gouv.fr> wrote: > >> Hi list, >> >> I am sorry for the very late answer concerning draft 18, but we >> (ANSSI) have several remarks after proof-reading the current >> specification. >> >> We are sorry for the multiple long messages. >> >> If the WG is interested by some of our concerns/proposals, we would be >> glad to propose some PRs. >> >> >> = Message splitting and interleaving = >> >> How to split and interleave subprotocols in TLS has not been clearly >> specified in the past, and it would be useful to be crystal clear on >> this point. >> >> In the specification, the subject is first presented in 4.5 (P.61): >> Handshake messages sent after the handshake MUST NOT be interleaved >> with other record types. That is, if a message is split over two or >> more handshake records, there MUST NOT be any other records between >> them. >> But I am wondering why this text only concern "messages after the >> handshake". It should always be the case! >> >> It is next present in section 4.5.3 (P.64): >> Handshake messages MUST NOT span key changes. Because the >> ServerHello, Finished, and KeyUpdate messages signal a key change, >> upon receiving these messages a receiver MUST verify that the end of >> these messages aligns with a record boundary; if not, then it MUST >> terminate the connection with an "unexpected_message" alert. >> >> And then in section 5 (mostly P.64 and P.65) plus a repetition P.69. >> >> >> It is worth noting that this specific point was (at least partially) >> the origin of several security issues: >> - the alert attack (https://www.mitls.org/pages/attacks/Alert); >> - Heartbleed (where OpenSSL answered with a fragmented record whereas >> it was not the spirit of the spec); >> - the OpenSSL Downgrade attack in 2014. >> >> Some of this is covered in the current specification, but it might be >> worth being even stricter: >> - regarding splitting/merging, they should be forbidden by default; >> - the default would apply to alerts (currently, the spec states that >> alerts MUST not be split, but they should not be merged either >> for simplicity's sake and since it is useless); >> > > +1. We (BoringSSL) and I believe NSS already forbid this for alerts at all > versions. > > This rule is actually implied by TLS 1.3 already, because we've gotten rid > of warning alerts. All alerts terminate the connection, except for > end_of_early_data, and end_of_early_data immediately signals a key change. > So it is not legal to send two alerts in the same epoch, much less in the > same record. (Being explicit about this is good, of course.) > This seems fine. I would take a PR for this. - incidentally, the default behaviour would apply to Heartbeat, as >> was the intent of the specification; >> - ApplicationData should be considered as a stream with possibly >> 0-length records >> - Handshake messages should either come as a sequence of multiple >> *entire* messages, or as a fraction of *one* message. That is, >> the number of HS messages inside one record should either be a >> round number or strictly less than 1. >> > > What simplifications were you expecting out of this? It seems to me this > would be a nuisance to both enforce as a receiver and honor as a sender. > > Our implementation doesn't try to pack handshake messages into records, > but I believe NSS does. NSS folks should confirm, but I expect such > implementations just buffer the messages up and flush when the buffer > exceeds the records size. That means all kinds of splits are plausible: > > [EncryptedExtensions Certifi] > [cateRequest Certificate Cer] > [tificateVerify Finished] > Yeah, that's how this works in NSS. I'm not seeing a real benefit in prohibiting this behavior. -Ekr I share your dislike of the way handshake messages and record boundaries > interact (or, rather, don't), but I'm not sure how this rule helps. > > >> These constraints can be expressed in 5.1 and cover most of the >> problematic cases. They are easy to check and to enforce. >> >> >> However, the problem of the OpenSSL Downgrade flaw (where the first >> record containing the beginning of the ClientHello was cut before the >> ClientHello.version field) will still stand, but there is no simple >> way to fix this, since version negotiation can now happen anywhere in >> the ClientHello extensions, so it might be impossible to enforce that >> the client versions are sent in the first record. >> >> I might volunteer some text if there is an interest of the WG. >> >> >> Olivier Levillain >> >> _______________________________________________ >> 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 > > --001a114dac9cde5ffa0541ec13b9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2016 at 2:18 PM, David Benjamin <<= a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium= .org> wrote:
On Tu= e, Nov 22, 2016 at 2:05 PM Olivier Levillain <olivier.levillain@ssi.gouv.fr<= wbr>> wrote:
Hi list,

I am sorry for the very late answer concerning draft 18, but we
(ANSSI) have several remarks after proof-reading the current
specification.

We are sorry for the multiple long messages.

If the WG is interested by some of our concerns/proposals, we would be
glad to propose some PRs.


=3D Message splitting and interleaving =3D

How to split and interleave subprotocols in TLS has not been clearly
specified in the past, and it would be useful to be crystal clear on
this point.

In the specification, the subject is first presented in 4.5 (P.61):
=C2=A0 =C2=A0Handshake messages sent after the handshake MUST NOT be interl= eaved
=C2=A0 =C2=A0with other record types.=C2=A0 That is, if a message is split = over two or
=C2=A0 =C2=A0more handshake records, there MUST NOT be any other records be= tween
=C2=A0 =C2=A0them.
But I am wondering why this text only concern "messages after the
handshake".=C2=A0 It should always be the case!

It is next present in section 4.5.3 (P.64):
=C2=A0 =C2=A0Handshake messages MUST NOT span key changes.=C2=A0 Because th= e
=C2=A0 =C2=A0ServerHello, Finished, and KeyUpdate messages signal a key cha= nge,
=C2=A0 =C2=A0upon receiving these messages a receiver MUST verify that the = end of
=C2=A0 =C2=A0these messages aligns with a record boundary; if not, then it = MUST
=C2=A0 =C2=A0terminate the connection with an "unexpected_message"= ; alert.

And then in section 5 (mostly P.64 and P.65) plus a repetition P.69.


It is worth noting that this specific point was (at least partially)
the origin of several security issues:
=C2=A0- the alert attack (https://www.mitls.org/pages/attacks/Alert);
=C2=A0- Heartbleed (where OpenSSL answered with a fragmented record whereas=
=C2=A0 =C2=A0it was not the spirit of the spec);
=C2=A0- the OpenSSL Downgrade attack in 2014.

Some of this is covered in the current specification, but it might be
worth being even stricter:
=C2=A0- regarding splitting/merging, they should be forbidden by default; =C2=A0- the default would apply to alerts (currently, the spec states that<= br class=3D"m_1219766863015853986gmail_msg"> =C2=A0 =C2=A0alerts MUST not be split, but they should not be merged either=
=C2=A0 =C2=A0for simplicity's sake and since it is useless);

+1. We (BoringSSL) and I believe NSS already forbid this for alerts a= t all versions.

This rule is actually implied by T= LS 1.3 already, because we've gotten rid of warning alerts. All alerts = terminate the connection, except for end_of_early_data, and end_of_early_da= ta immediately signals a key change. So it is not legal to send two alerts = in the same epoch, much less in the same record. (Being explicit about this= is good, of course.)

Thi= s seems fine. I would take a PR for this.


=C2=A0- incidentally, the default behaviour would apply to Heartbeat, as =C2=A0 =C2=A0was the intent of the specification;
=C2=A0- ApplicationData should be considered as a stream with possibly
=C2=A0 =C2=A00-length records
=C2=A0- Handshake messages should either come as a sequence of multiple
=C2=A0 =C2=A0*entire* messages, or as a fraction of *one* message.=C2=A0 Th= at is,
=C2=A0 =C2=A0the number of HS messages inside one record should either be a=
=C2=A0 =C2=A0round number or strictly less than 1.

What simplifica= tions were you expecting out of this? It seems to me this would be a nuisan= ce to both enforce as a receiver and honor as a sender.

Our implementation doesn't try to pack handshake messages into re= cords, but I believe NSS does. NSS folks should confirm, but I expect such = implementations just buffer the messages up and flush when the buffer excee= ds the records size. That means all kinds of splits are plausible:

=C2=A0 [EncryptedExtensions Certifi]
=C2=A0 [cat= eRequest Certificate Cer]
=C2=A0 [tificateVerify Finished]
<= /div>

Yeah, that's how this works= in NSS.

I'm not seeing a real benefit in proh= ibiting this behavior.

-Ekr

I share your dislike of the way handshake messages and record boundaries= interact (or, rather, don't), but I'm not sure how this rule helps= .
=C2=A0
These constraints can be expressed in 5.1 and cover most of the
problematic cases.=C2=A0 They are easy to check and to enforce.


However, the problem of the OpenSSL Downgrade flaw (where the first
record containing the beginning of the ClientHello was cut before the
ClientHello.version field) will still stand, but there is no simple
way to fix this, since version negotiation can now happen anywhere in
the ClientHello extensions, so it might be impossible to enforce that
the client versions are sent in the first record.

I might volunteer some text if there is an interest of the WG.


Olivier Levillain

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.o= rg/mailman/listinfo/tls

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a114dac9cde5ffa0541ec13b9-- From nobody Tue Nov 22 16:28:19 2016 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 20BCE1293F8 for ; Tue, 22 Nov 2016 16:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JcndyoxvCbWh for ; Tue, 22 Nov 2016 16:28:16 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 8E3081293E3 for ; Tue, 22 Nov 2016 16:28:16 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id p16so23827927qta.0 for ; Tue, 22 Nov 2016 16:28:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jz2spLDHSLdxXDrtm/DVy2uEGbmGCSqpuy1MBEGCaKI=; b=TPdlBTq5ED+U2yVFOBrodZoBsZW1jmiBsZcNxayVIKU407irYo/XmyZneiR0cjpG7p LFGJ/FSdLp11uAxIWkQVigtyQLOvbws5b3skO9495rfV1PplbEL/szk52qPLwBebO/nY uklXiz56BYs01XhgJulVJtu8kqfz+0UaIZX8gwrq3orHWwI11YzylCEUxLLty98JSF7v i1tXtBfMSKX4WZlvaqn9jLvR226EVg/t+TvgYAhR/aLPUfKi8/f3MsItGkiQvEb8eGU+ rVN9JA1BqUeeoQirnyRabgDK3D7xxllJ4hEYDHghcP+YZsSs3QbZ7DoDBIfKwEGptdmK NrsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jz2spLDHSLdxXDrtm/DVy2uEGbmGCSqpuy1MBEGCaKI=; b=eYMYbL0v+MuO0FqNqydO+rkJlLyUHQqTwD4cvG5dmlIvNxHUHvHYdKkrI20bjBYmdq J/Cnizy4HvmoC2qvyMLiDDLi9q9we+UcntdczkF40DR2zkuWbacRsM+q8i4NTjvmOoZv VKlsVL6NUB5+NTlXLr4okjAKLirTDLjG6wwZSbg7LIaTAQMpmMT3yMvQXRB+w778JApi mQZ7h6zEQ5H6J3WCSdFu/HbQ4ekEGk//kYI2wQbFWzyJLqBqOKS5wkbsfU1U0EZj8i89 Fw4bPCp/DxbhQF4TAssb+VF1SCbX61km3euHDY+rncBFiy+iHcg0JBJ2EqCrbvPbLVEX GJpg== X-Gm-Message-State: AKaTC02qTT5j5o3dq6Wg2kpPhQXsOF/9/Ik41S1qrAzkD5sZ4ZOHQsdJlEudl73vyT2LXC9rS/YIdUVR6a/13w== X-Received: by 10.237.44.161 with SMTP id g30mr347512qtd.144.1479860895561; Tue, 22 Nov 2016 16:28:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Tue, 22 Nov 2016 16:28:15 -0800 (PST) In-Reply-To: <20161122190720.GE19978@neoplankton.picty.org> References: <20161122190720.GE19978@neoplankton.picty.org> From: Martin Thomson Date: Wed, 23 Nov 2016 11:28:15 +1100 Message-ID: To: Olivier Levillain Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 00:28:18 -0000 On 23 November 2016 at 06:07, Olivier Levillain wrote: > > In 4.2.8 (P.47), the server receiving early_data "can behave in one of > two ways"... followed by three cases. Beside the typo, the first case > could be phrased differently. Actually, it reads > > - Ignore the extension and return no response. This indicates that > the server has ignored any early data and an ordinary 1-RTT > handshake is required. > > Since an ordinary 1-RTT handshake will require the server to actually > send a response (the ServerHello), it might be better to put it this > way: > > - Ignore the extension and return a standard 1-RTT ServerHello. > This indicates that the server has ignored any early data and > an ordinary 1-RTT handshake is required. Here's a PR: https://github.com/tlswg/tls13-spec/pull/773 I've gone a little bit further than what Olivier suggests and pointed out in each of these that the server is required to ignore early data. From nobody Tue Nov 22 16:36:46 2016 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 3EFBC1293E4 for ; Tue, 22 Nov 2016 16:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjuedHwXCNIe for ; Tue, 22 Nov 2016 16:36:44 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 E4799120727 for ; Tue, 22 Nov 2016 16:36:43 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id x190so48470623qkb.0 for ; Tue, 22 Nov 2016 16:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UJv8fP2QBocu8eX2oPVronWh/3gDSEzUhOUxBF7AsIg=; b=GdGXDSsDnJB2p5Bgi2oGp5YCrPYmdftWKSIHdFS9SYYBFH6fTUvA8VaNIf4ujpqlEu xPwmFQLud3Ssrz8gUyMKiou1CV3TD2b60nnCzeCkokYZyIefb9cBFYdN+oc/eI6O3Lbs 0judl6VsltlIuaQAnbKzqxIVQXP119wnpBpRhY56A/RQcrPedILVaHmAHSoK0wdVNONJ HA+weD04o3xNAfowXPrpY3KmKTEN4FGPTP4zeoYRxR7nTwY+yDUOfFcf+cIYJP58GOXc 9+xJSeND+dJ1Xl7jt5I94EKylyHIl7btxE1dEpeGe2sZlirA+lrdct82xxQK1diDhJyM E+4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UJv8fP2QBocu8eX2oPVronWh/3gDSEzUhOUxBF7AsIg=; b=Gb9qISkkHk8XTbMu0e0jIDF+Ymbn1wIcTOZN2kElpIKLcS3rOBfrqAnzWjuFcmgKEE J90lVnv3+YngKFJF0qE7u6TgM2p25ije27gO5fdP/M3eaB85v3JUxWJvku1CpaSM3IMd LcK+AFhrEYq6oTe4wOlc2ZlxNhovgbjhjOVraavg4J7cu1lvB97n5KjDznuBqz47QMGk zdFgSte8AmXJq2RMADqbZWPhu/YKSojrvfla05/RE4XoInk8yLfT+cnoxdQRqTs9et/i X9ojKfbf8LasuY5V/0mteX8/IuqEXriJxYoP2bgbcsHPKZslfeoqGD8RYMau0B6zZnsR 6PfQ== X-Gm-Message-State: AKaTC01CcddRp3h5ihjFT+L8ird7L8BuJ12SsZXi+w2maicQAUef/CPRgjeihDh7F3XEcCW02zL0FfiWTkGckA== X-Received: by 10.55.12.2 with SMTP id 2mr406954qkm.68.1479861402988; Tue, 22 Nov 2016 16:36:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Tue, 22 Nov 2016 16:36:42 -0800 (PST) In-Reply-To: References: <20161122190822.GH19978@neoplankton.picty.org> From: Martin Thomson Date: Wed, 23 Nov 2016 11:36:42 +1100 Message-ID: To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Message splitting and interleaving X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 00:36:45 -0000 On 23 November 2016 at 10:24, Eric Rescorla wrote: >> [EncryptedExtensions Certifi] >> [cateRequest Certificate Cer] >> [tificateVerify Finished] > > > Yeah, that's how this works in NSS. To be clear, NSS buffers an entire flight of messages and then sends them. It might fragment things between TCP segments as a result, but usually fits everything in a single record (with some exceptions, thanks to CertificateRequest being bloated, foor example). (In DTLS, it's more complicated because we have MTU detection, but the same basic principle applies.) Like others, I would find stricter rules around record splits very hard to enforce, and for not much gain. From nobody Tue Nov 22 16:45:55 2016 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 A3DE21294A7 for ; Tue, 22 Nov 2016 16:45:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 epWmibVg_DfV for ; Tue, 22 Nov 2016 16:45:50 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 5E38A12948C for ; Tue, 22 Nov 2016 16:45:50 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id r204so29412691ywb.0 for ; Tue, 22 Nov 2016 16:45:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZwueIQE7sX8wPTBV24D33zdtAQ+pOOYL66o9ZDXMDZ8=; b=DG521xaGvvwfspjK9ZVn/afeW5HExZ7VOCfLE0IwPatABIUwXDEWuPcKr70IhFdQW5 HOVBUH4iCs6apHNuOibi7hcn+E2/tTeh0s50dz9szKMnrCrUOi+ufoebRpgRLj5TsCPK csz6O4Ri8MUJ5nGN7WPwPVfHCpOLGE28W6apaGw1zGp0QaOGn6rh6+jEvONC1md2/+uq Jhfem1h0xw20iiFASoRfxXYub33hrgxw4UA62vgIKgsb7MinWLWIsqQs6Q/kR/zouSlv hLmX/xnw8sF6SaLZAnwKSqQ0gmWvd0fLpbSHPD6Vz9kWOM3PKYoeXgvSgccwePnWl1h7 A7hQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZwueIQE7sX8wPTBV24D33zdtAQ+pOOYL66o9ZDXMDZ8=; b=Inbf0LGxoLHXoIYjZfLyripb3VJvZ1gpVNIFNHk+NdBOnh+2CFBW7ZZbqtU68GURoH By8ZSYZUNVWBkhrzariPpCnin/aF/zveHvOti3J0KGULrHhi6xcblrW+Onp2T57rpEjW KLZvGfsqwJ+6R6ve3NQNSx/qu+KaQ77fZpYivAtqmUroBNCDmjWY+DleftYStD5QhRmk 9Bsd51T5O1VR025PoXTBRqMPXDrgfNU77OPgbUtoCI6KbY1bW/nSEWWxnQ03TNwHiVW1 T8/ZaKk8NetkKysNd4QMyzu9sBehDWcpt/I9d6hCPlBIqmylcvfUW56QBC4bXo3C6JhV ljRw== X-Gm-Message-State: AKaTC00JWXSrg5DbMWF1gS0wUSYo26A4EC6Va16gFMD5KsfGM1dyLQX5P3R3YJWl72sTViCEQTlcix4tnTzWMQ== X-Received: by 10.129.81.78 with SMTP id f75mr427143ywb.149.1479861949631; Tue, 22 Nov 2016 16:45:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Tue, 22 Nov 2016 16:45:09 -0800 (PST) In-Reply-To: References: <20161122190822.GH19978@neoplankton.picty.org> From: Eric Rescorla Date: Tue, 22 Nov 2016 16:45:09 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a11456404d34c580541ed3538 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Message splitting and interleaving X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 00:45:51 -0000 --001a11456404d34c580541ed3538 Content-Type: text/plain; charset=UTF-8 On Tue, Nov 22, 2016 at 4:36 PM, Martin Thomson wrote: > On 23 November 2016 at 10:24, Eric Rescorla wrote: > >> [EncryptedExtensions Certifi] > >> [cateRequest Certificate Cer] > >> [tificateVerify Finished] > > > > > > Yeah, that's how this works in NSS. > > To be clear, NSS buffers an entire flight of messages and then sends > them. It might fragment things between TCP segments as a result, but > usually fits everything in a single record (with some exceptions, > thanks to CertificateRequest being bloated, foor example). (In DTLS, > it's more complicated because we have MTU detection, but the same > basic principle applies.) > Yes, this is what I meant to say. Basically, it tries to cram as much as it can into one record and the answer to "as much as it can" is "it depends" -Ekr Like others, I would find stricter rules around record splits very > hard to enforce, and for not much gain. > --001a11456404d34c580541ed3538 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Nov 22, 2016 at 4:36 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 23 November 2016 at 10:24, Eric Rescorla <ekr@rtfm.com> wrote:
>>=C2=A0 =C2=A0[EncryptedExtensions Certifi]
>>=C2=A0 =C2=A0[cateRequest Certificate Cer]
>>=C2=A0 =C2=A0[tificateVerify Finished]
>
>
> Yeah, that's how this works in NSS.

To be clear, NSS buffers an entire flight of messages and then sends=
them.=C2=A0 It might fragment things between TCP segments as a result, but<= br> usually fits everything in a single record (with some exceptions,
thanks to CertificateRequest being bloated, foor example).=C2=A0 (In DTLS,<= br> it's more complicated because we have MTU detection, but the same
basic principle applies.)

Yes, this is = what I meant to say. Basically, it tries to cram as much as it can into
one record and the answer to "as much as it can" is "= it depends"

-Ekr

Like others, I would find stricter rules around record splits very
hard to enforce, and for not much gain.

--001a11456404d34c580541ed3538-- From nobody Tue Nov 22 20:41:13 2016 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 EDDA4129429 for ; Tue, 22 Nov 2016 20:41:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QfmNzdY8LNkR for ; Tue, 22 Nov 2016 20:41:10 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (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 6BEA21294EB for ; Tue, 22 Nov 2016 20:41:10 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id t79so4233328wmt.0 for ; Tue, 22 Nov 2016 20:41:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding; bh=CMlcxBDAbGKFLCGGEamC2aLSxXKUo+dbhKUrMAhCN8I=; b=gD4dNir4jN4jm06G/ugSF+xT2lFEw+oIeyE8CFX2ThuDk5eRkk5bz/xVlQWnaLwWKR vCgIB7u+mdtlEVEjnmXKt/sXFVSbDcwn0NW/91OEXBlub+B25ClFT1fnkQYRkYTvKj1G YSWYxnd6zR2iC2i03bGQFj8i8uzVOU0+RiuxW+VBCz/Vb3GRwCZ8kcmlC8aDj/8hDRhH /tALSjbmSHSrwUnxqznRn5rqyjSI8Sb1che04D55XsilTh6/0wAtJC+2zPjVWarZX0P7 l+c1/NbSWA4lMj4444G7+j3UWyFd9O36gmtgrUo0QfbQoWyFLkhnmefuKsbUUufiA4Sj QCDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CMlcxBDAbGKFLCGGEamC2aLSxXKUo+dbhKUrMAhCN8I=; b=LwIQlhmub4bcxYL6/g671oXNQ2EelR/kFcQSZlyyeEKKSonYgJx0jblHMarKm3Yzci QSRoG1DNXh9GfkA17boj8GwsQRQiWd866RsGPDLzuxC9SgsohY9u3K94lRc0vDYVV4YD cWFHJAdSzIB8+yh66DD1l8t6KtRmxP4YeeZ1xTyFkffDywbGXcOLmrBTdu9JYD4C8rJR foMekm1B5BMga73gyKMdW+koD4dU1kbxsqOuck759zpG7Ox2c+TjSGtdNGquGZZ88zZL T1ev5RXjbzJWkPNywc4x93Gqzdk75eR1IquxzHCw/uAWOBYqYNzc7LFy7it735HXb5GY nq9w== X-Gm-Message-State: AKaTC01IoNquJhwEBf/H7x26WEQoVIcS2JIr48os+Nh1CPIpC06rpmWhlTAXYs7oG1tDuw== X-Received: by 10.28.96.4 with SMTP id u4mr5611119wmb.86.1479876068732; Tue, 22 Nov 2016 20:41:08 -0800 (PST) Received: from [192.168.1.79] (124.25.176.95.rev.sfr.net. [95.176.25.124]) by smtp.googlemail.com with ESMTPSA id f67sm532944wmd.13.2016.11.22.20.41.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Nov 2016 20:41:07 -0800 (PST) To: tls@ietf.org References: <201611221706.50692.davemgarrett@gmail.com> From: Anders Rundgren Message-ID: <3c1dd0f0-1833-83d1-ef17-9cab86559675@gmail.com> Date: Wed, 23 Nov 2016 05:40:52 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <201611221706.50692.davemgarrett@gmail.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 04:41:12 -0000 Using the YEAR as Version was created to make sure that users having old versions of products that are constantly upgraded would feel the pressure to upgrade. This idea doesn't seem equally suitable for security protocols. TLS 4 would IMO be a logical choice since it is numerically higher than all its predecessors. Anders From nobody Tue Nov 22 21:25:51 2016 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 28377129554 for ; Tue, 22 Nov 2016 21:25:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gfwdGlaNPZdD for ; Tue, 22 Nov 2016 21:25:49 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 CAE2412952F for ; Tue, 22 Nov 2016 21:25:48 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id n21so3020575qka.3 for ; Tue, 22 Nov 2016 21:25:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to; bh=O+wPkomAzuysas9j/Ycz01EaC92NIgJjFACTE2ZlS4Y=; b=qqoA0A+PweA6oQTMtlxDuTpq6rl8cMMIhTQMKLNV8kQU6DDUuQ5n0GWKPJq0UgvSJ9 gSeG/DTQye31Gs11becH6xCObSs4UizKuxzh/sC1srIkefUOoenESVzXdGvd4yMOClt9 xdZ02t79Wo/yumQKWqHiEKnq28Qq3PfbmQv3g5zy5J2Hql2dNVH9Ea1lnmMqpWZ5EBEr V72YLo2Q/7rGr5WeSucoMOf+ngYXz1dVNX2AiXZN1lZH6mzu0JfhLqCl1kOfZz1WDmDj IsE5qihCScGS3yVVExmN7v4HBPzG6IdD9OaOh1Ak877coGEkw+eTphYUgCy3s+vLff8v i5pw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=O+wPkomAzuysas9j/Ycz01EaC92NIgJjFACTE2ZlS4Y=; b=Vim6HHBgO9XoJh2uBi3m8Cf+hFAC1gMTGp4qK4b4yebW6T279T2BnzUJE9dR04A1v3 PUtItXRFLFm70eRIaZ2+Shqw/80K/QkmIkJZMc4pIz+YlTckdlY5vZ4Kva7K3CZi4GrO DpTujSxbwGlLp1jErit2kgoS/e7S5my9ROn5O/ANCGiysal+uPJZosCW/AXOEFEhx+uV c1wZ3FC31PR1htICDNyAYLfaE0IxkFIP4uCNfwcIlJ20gWoGhVTgoqJEtiqYKUj+kYsU hgAaxvv4OK8CBJy+r0STtt0cafw2srrYk26CkUV+ATrd2BkDTuBKUctXhKY8sARGMXGX 7Wiw== X-Gm-Message-State: AKaTC00iElmROWbiv/cULN0E4a6R7iLvZFLfTZBcgP1c5nU6vkvsqYM4iO3z2zcttAigeclbZuCwVVHTKFG2CQ== X-Received: by 10.55.158.199 with SMTP id h190mr1300136qke.202.1479878747903; Tue, 22 Nov 2016 21:25:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Tue, 22 Nov 2016 21:25:47 -0800 (PST) From: Martin Thomson Date: Wed, 23 Nov 2016 16:25:47 +1100 Message-ID: To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [TLS] Labels in HKDF-Expand-Label X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 05:25:50 -0000 The grammar for the label permits the label to be 9 octets long. That's the exact length of the prefix. That means that it is valid to use an exporter with an empty label string. That seems dangerous. I propose that we require at least one octet: https://github.com/tlswg/tls13-spec/pull/774 From nobody Tue Nov 22 21:27:51 2016 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 7E36C129460 for ; Tue, 22 Nov 2016 21:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 lkIQkG0uyUNq for ; Tue, 22 Nov 2016 21:27:49 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 EB6E3129401 for ; Tue, 22 Nov 2016 21:27:48 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id i145so2466519ywg.2 for ; Tue, 22 Nov 2016 21:27:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=F/3Ri1twGnVu/b51VbS9oAsVsFzZfNaIg08YfunekoI=; b=cqPxsPsxACsx8+JKgkqJ0Vx+uPHQ5/KgBOA8LfH1mP0XsouRs0Lj3okEet4Z8vqqQk 3ETg9QTp+LAeDWJJJfPwxRVDsadQyAi492/ezXxIQiRJ2HsVgjzZliUvF5OStopvCvFM /okGoDLjxsnftZ5WPH4y0ArPOumsuC81yTpezh4Nyhdh+gwaMAPr2GweyeOdCm94F+IB KHmsx0pVqUnFp/LuOS0Gulqa/UOiEcZ07nCqufB1JvHVZq8EuUmMWRfqvt78WD1FA9Mx 7S6y4HemzHkRqSrv8cRZv4wIknTB8+8oCKzPoRVrnYuDwvcDk64VRqFFLiRWDo7sn2/8 oqMw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=F/3Ri1twGnVu/b51VbS9oAsVsFzZfNaIg08YfunekoI=; b=Ck6xlacxZAW5vZpLWQlyS7NXKJDGj7U+KXLgNdu51O5rKlUEYvUDlheTi78E26P4oq Kcdq0sIqQ1Ov2EKhn4S8DhMO4BWoS747bq04esYuHWvSAOmhS5DXTlCUgx+JdR124s4P hLRUglxTYe1gXF3io1v66/r1mV8LX8BPRON8/aXR61vGDOgxL8fB5FXA9Ibd1R/ckJ0N e1qgRiCWewqdT6zev9SI8ToJAj9lDMpTWdGFo3WR7biAqJsh7NgzUCS0uQMCKG4XsMJc pBuBeYjx8rfE9CHct99ckdqpCHerjNDKmBbUeyNg3v8P5KMMzBwk1hIdxR+5HfGU7O5o ZyQw== X-Gm-Message-State: AKaTC03a/gH3RwUPrlVbczpJM+pjKM35qsyvb7U8DW5UVrpOmad6t82jUl1i2LUE/xmSwh7g179yO8NzkdWBuQ== X-Received: by 10.129.108.216 with SMTP id h207mr1443287ywc.52.1479878868167; Tue, 22 Nov 2016 21:27:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Tue, 22 Nov 2016 21:27:07 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Tue, 22 Nov 2016 21:27:07 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114dd36e3f9db80541f1266c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Labels in HKDF-Expand-Label X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 05:27:50 -0000 --001a114dd36e3f9db80541f1266c Content-Type: text/plain; charset=UTF-8 Actually all future EXPORTERs need to start with EXPORTER-. But this does seem like a reasonable change so I have merged it -Ekr On Tue, Nov 22, 2016 at 9:25 PM, Martin Thomson wrote: > The grammar for the label permits the label to be 9 octets long. > That's the exact length of the prefix. > > That means that it is valid to use an exporter with an empty label > string. That seems dangerous. I propose that we require at least one > octet: > > https://github.com/tlswg/tls13-spec/pull/774 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dd36e3f9db80541f1266c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Actually all future EXPORTERs need to start with EXPORTER-= . But this does seem like a reasonable change so I have merged it

<= /div>
-Ekr


On Tue, Nov 22, 2016 at 9:25 PM, Martin Thomson <martin.thomson@gmail.com> wrote:
The grammar for the label permits the label to be 9 octets lo= ng.
That's the exact length of the prefix.

That means that it is valid to use an exporter with an empty label
string.=C2=A0 That seems dangerous.=C2=A0 I propose that we require at leas= t one
octet:

https://github.com/tlswg/tls13-spec/pull/774
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114dd36e3f9db80541f1266c-- From nobody Tue Nov 22 23:06:45 2016 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 1F3F8129502 for ; Tue, 22 Nov 2016 23:06:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 VX7KBTwlrBKJ for ; Tue, 22 Nov 2016 23:06:42 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17C6A1294FD for ; Tue, 22 Nov 2016 23:06:42 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C6D1E8FCF4 for ; Wed, 23 Nov 2016 07:06:41 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.184]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAN76diO020593 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Wed, 23 Nov 2016 02:06:41 -0500 Message-ID: <1479884799.2563.3.camel@redhat.com> From: Nikos Mavrogiannopoulos To: "tls@ietf.org" Date: Wed, 23 Nov 2016 08:06:39 +0100 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Wed, 23 Nov 2016 07:06:41 +0000 (UTC) Archived-At: Subject: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 07:06:43 -0000 Hi,  Up to the current draft of TLS1.3 the record layer is restricted to sending 2^14 or less. Is the 2^14 number something we want to preserve? 16kb used to be a lot, but today if one wants to do fast data transfers most likely he would prefer to use larger blocks. Given that the length field allows for sizes up to 2^16, shouldn't the draft allow for 2^16- 1024 as maximum? regards, Nikos From nobody Wed Nov 23 00:06:05 2016 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 2CDA91295BC for ; Wed, 23 Nov 2016 00:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wjJCK5o33hTv for ; Wed, 23 Nov 2016 00:06:01 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (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 10FB81293FD for ; Wed, 23 Nov 2016 00:06:00 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id t79so10825423wmt.0 for ; Wed, 23 Nov 2016 00:06:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=evkbCqdgpMU2oYwQGeYY/kzB6JZqVDCqeAHJwJ3jY38=; b=tBfEMyQGhnnF08hQrjPKU7Kq8Aw/vW0edrbmRrqow0tsaWQoiQiEypaS6YNHo46p7w zvJhn4nLv462N5iJ5lqkpNrXXQmJf8et1SL0bsKICpa1IWIhJZFZfi2SPEZjf4D1lspw UNVk1p1YzUCC4UxiwRrcwlKY79SrodkNTc4cNtn/A/qOpKLRry1neWPvQ/nPJKCazbhv VCUzh9OIKMV4fVXIa7IWeMWFh9UaSmDBN1VK3w7t3lbMfkJAQdlO0hsfFqKZ540YjWYB 1AhKO7MgZhfsbpnvWhQ3xX8XFJ1TJ0urNuiuh/4byzh86tW//j1l6+li7xtKMK0B5Q/D IZVA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=evkbCqdgpMU2oYwQGeYY/kzB6JZqVDCqeAHJwJ3jY38=; b=l2Uh0INuSjNbNYk4HhULxjK5ypGiSP/Le2kxOoKF61I5oDqOAAb+M/0uyfe2hbbxxi TCcot4YGG7C4M4bX2aL8151qK+ds5PuxHdCLwPKILVQPp/yMyOew/qdVOccTY5dlu9qR yep8wTe+Z9c99+dDz48vSnWIXbaWkTSYLtO96+WhjWepSPRgiDzr0cv4KyG9KydKshO3 J7nVbLJZ80I6ZGp4+XrtBbfynbFPMQwt8MtokkVOpSiJOAeZtk342FH8Y9oQo1I2tRm0 Up/wYJmuEJq+v6p1aZeS8GSYykE6PMuT1IXCVwuBSp0HuT5nC2OFYYFE05i6EXI80L+D Nw1Q== X-Gm-Message-State: AKaTC00GhXdwBKeG+ckPafZ4eUMI8z/BHhgCXAGPsQf4BOQuibtoRdeUh8a37ztD4xoGRw== X-Received: by 10.28.27.133 with SMTP id b127mr6314479wmb.59.1479888359459; Wed, 23 Nov 2016 00:05:59 -0800 (PST) Received: from [172.24.250.223] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id p144sm1322139wme.23.2016.11.23.00.05.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 00:05:59 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: <1479884799.2563.3.camel@redhat.com> Date: Wed, 23 Nov 2016 10:05:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1479884799.2563.3.camel@redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:06:03 -0000 Hi, Nikos On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos = wrote: > Hi, > Up to the current draft of TLS1.3 the record layer is restricted to > sending 2^14 or less. Is the 2^14 number something we want to = preserve? > 16kb used to be a lot, but today if one wants to do fast data = transfers > most likely he would prefer to use larger blocks. Given that the = length > field allows for sizes up to 2^16, shouldn't the draft allow for 2^16- > 1024 as maximum? I am not opposed to this, but looking at real browsers and servers, we = see that they tend to set the size of records to fit IP packets. The = gains from increasing the size of records from the ~1460 bytes that fit = in a packet to nearly 64KB are not all that great, and the gains from = increasing records from 16 KB to 64KB are almost negligible. At that = size the block encryption dominates the CPU time. Yoav From nobody Wed Nov 23 00:20:02 2016 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 8D14F129617 for ; Wed, 23 Nov 2016 00:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 PpKPO0XPgkMv for ; Wed, 23 Nov 2016 00:19:47 -0800 (PST) Received: from smtp.ssi.gouv.fr (smtp.ssi.gouv.fr [86.65.182.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3DF3129629 for ; Wed, 23 Nov 2016 00:19:47 -0800 (PST) Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id 69BB790B8D4; Wed, 23 Nov 2016 09:19:46 +0100 (CET) To: Eric Rescorla , Steven Valdez References: <20161122190344.GC19978@neoplankton.picty.org> From: Olivier Levillain Message-ID: <58355120.5030800@ssi.gouv.fr> Date: Wed, 23 Nov 2016 09:19:44 +0100 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:19:49 -0000 Hi, >> Being able to send supported_groups does allow a server to choose to make >> a tradeoff between an extra round trip on the current connection and its >> own group preferences. One example where a server might want to do this is >> where it believes that X25519 is likely a more future-proof group and would >> prefer that, but still believes the client's choice of P256 is suitable for >> this connection. Always requiring an extra round trip might end up being >> expensive depending on the situation so some servers might prefer to avoid >> sending an HRR for a slightly more preferred group. >> >> I think that requiring the client to maintain state from the >> supported_groups puts undue requirements on the client, since not all >> clients keep state between connections, and those that do usually only keep >> session state for resumption. >> > This matches my view as well. > > I agree that the client should not be require to keep state. I do not > believe that the draft requires this, but if someone thinks otherwise, > please send a PR to fix. > There were actually two points in my message: - I was not convinced by this way of signalling a preference without enforcing it, but I understand that, if we keep supported_groups, it does not cost much and the client can safely ignore the server sent extension; - however, I found strange that the specification stated that the client could update its view when seeing this extension, but that it was not stated in the case of an HRR where updating its views of the servers' preference would clearly be useful for the future. I only proposed to add the same text "The client MAY update its view of the server's preference when receiving an HRR, to avoid the extra round trip in future encounters". olivier From nobody Wed Nov 23 00:30:12 2016 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 46E41129635 for ; Wed, 23 Nov 2016 00:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 ziMTL8raDDTw for ; Wed, 23 Nov 2016 00:30:09 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46B8E129599 for ; Wed, 23 Nov 2016 00:30:09 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id DAFEF80F93; Wed, 23 Nov 2016 08:30:08 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.184]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAN8U6f7004766 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Nov 2016 03:30:08 -0500 Message-ID: <1479889806.2563.15.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Yoav Nir Date: Wed, 23 Nov 2016 09:30:06 +0100 In-Reply-To: References: <1479884799.2563.3.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 23 Nov 2016 08:30:08 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:30:10 -0000 On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: > Hi, Nikos > > On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos > wrote: > > > > > Hi, > >  Up to the current draft of TLS1.3 the record layer is restricted > > to > > sending 2^14 or less. Is the 2^14 number something we want to > > preserve? > > 16kb used to be a lot, but today if one wants to do fast data > > transfers > > most likely he would prefer to use larger blocks. Given that the > > length > > field allows for sizes up to 2^16, shouldn't the draft allow for > > 2^16- > > 1024 as maximum? > > I am not opposed to this, but looking at real browsers and servers, > we see that they tend to set the size of records to fit IP packets. IP packets can carry up to 64kb of data. I believe you may be referring to ethernet MTU sizes. That to my understanding is a way to reduce latency in contrast to cpu costs. An increase to packet size targets bandwidth rather than latency (speed). > The gains from increasing the size of records from the ~1460 bytes > that fit in a packet to nearly 64KB are not all that great, and the > gains from increasing records from 16 KB to 64KB are almost > negligible. At that size the block encryption dominates the CPU time. Do you have measurements to support that? I'm quite surprized by such a general statement because packetization itself is a non-negligible cost especially when encryption is fast (i.e., in most modern CPUs with dedicated instructions). regards, Nikos From nobody Wed Nov 23 00:33:09 2016 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 C617C129635 for ; Wed, 23 Nov 2016 00:33:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 RHxX1zW0SPE9 for ; Wed, 23 Nov 2016 00:33:05 -0800 (PST) Received: from smtp.ssi.gouv.fr (smtp.ssi.gouv.fr [86.65.182.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29E20129634 for ; Wed, 23 Nov 2016 00:33:05 -0800 (PST) Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id E14AF90B8DD; Wed, 23 Nov 2016 09:33:03 +0100 (CET) To: Eric Rescorla References: <20161122190101.GA19978@neoplankton.picty.org> From: Olivier Levillain Message-ID: <5835543F.4080600@ssi.gouv.fr> Date: Wed, 23 Nov 2016 09:33:03 +0100 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review: Downgrade protection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:33:07 -0000 Hi, > Thanks for your comments. I do want this section to be clear. > > It would be very helpful if you formatted this as a PR. That would make it > easier to understand the changes in this text. The text has been proposed as PR 775 (https://github.com/tlswg/tls13-spec/pull/775). olivier From nobody Wed Nov 23 00:39:08 2016 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 792AE129635 for ; Wed, 23 Nov 2016 00:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaHGIPkVFl_D for ; Wed, 23 Nov 2016 00:39:05 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 A4A0D129634 for ; Wed, 23 Nov 2016 00:39:04 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id g23so66771521wme.1 for ; Wed, 23 Nov 2016 00:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=JYPuv1ZXRcFeDl6s8w8Z4SW7ueXTw6PxNl3Txo4ZD4E=; b=T2fW5okYSUwEcrDHeQCpJ+29bZ1Md1HgxuOYPSM4kGYQo8G1WXznhHuL3PUp97/pRl dLNJi7vicFkwI9jTfVKXuaAVUYrNL4Lv7ULDmf5MTfBaEHUielT2SLabPYNnSUw3fBs9 8Yrc0bNZp8bb0bnRtlcpXbK7TanJ+LcBAErHohAXEEhbvShKMwz4LFu3bCwdBgDNCrFG BioLLKJ0cy1UkG9I4STQdIrnwfbh2WPAJXXUUWltnz0xjrbLOKo8LcfLS2+AVrseItV+ en8nCLyNKoYaTO/Ew/hefExMSES7EaZNCfqyJwzUngCIK8ZRTpB59fBMIYu8RG91cV9R x3+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=JYPuv1ZXRcFeDl6s8w8Z4SW7ueXTw6PxNl3Txo4ZD4E=; b=Frr4q67QsILQ0ark+dXmA15fIbZZBZd3svg3JcR+mhckaFXZP0RwbP9n7tZHgx1LS6 cHUV3543PJUOtf/sQj6ec+YhyhWVcQAYcduH9OPaZB4W+YlKOz9/w0zjlbAe8/87SNRF yqsBlKehDDdPHsEtGh8AVjH4c7Th7gkuylXlnIWg0KmPuUvfUq2KTWBzX7eCybHFY+4/ UQlIpr4W723wu3FBWFDR3ha0cfK5ZG7J3vlrjYlEz+jxrezgXUdl5+AH3w7p1wbw0ujw poFE6i+pKI4QXsmiRNrFAOMJNISn5Yu21EFXNiurNiw/xQ5yZTwOCVvUissfwAILyZit cx3A== X-Gm-Message-State: AKaTC03t7VzPIH0BopN1LFeseklAW7ZNjjvuPcIFfgUbCvVglPUvR+NQmQvefGuC36nZdcX8JRVCIQDg836uKg== X-Received: by 10.28.175.204 with SMTP id y195mr2281076wme.106.1479890343061; Wed, 23 Nov 2016 00:39:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.168.133 with HTTP; Wed, 23 Nov 2016 00:39:02 -0800 (PST) In-Reply-To: <1479889806.2563.15.camel@redhat.com> References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> From: Judson Wilson Date: Wed, 23 Nov 2016 00:39:02 -0800 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a11443834346d8f0541f3d2ee Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:39:06 -0000 --001a11443834346d8f0541f3d2ee Content-Type: text/plain; charset=UTF-8 Can you send multiple records in one data transfer to achieve whatever gains are desired? On Wed, Nov 23, 2016 at 12:30 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: > > Hi, Nikos > > > > On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos > > wrote: > > > > > > > > Hi, > > > Up to the current draft of TLS1.3 the record layer is restricted > > > to > > > sending 2^14 or less. Is the 2^14 number something we want to > > > preserve? > > > 16kb used to be a lot, but today if one wants to do fast data > > > transfers > > > most likely he would prefer to use larger blocks. Given that the > > > length > > > field allows for sizes up to 2^16, shouldn't the draft allow for > > > 2^16- > > > 1024 as maximum? > > > > I am not opposed to this, but looking at real browsers and servers, > > we see that they tend to set the size of records to fit IP packets. > > IP packets can carry up to 64kb of data. I believe you may be referring > to ethernet MTU sizes. That to my understanding is a way to reduce > latency in contrast to cpu costs. An increase to packet size targets > bandwidth rather than latency (speed). > > > The gains from increasing the size of records from the ~1460 bytes > > that fit in a packet to nearly 64KB are not all that great, and the > > gains from increasing records from 16 KB to 64KB are almost > > negligible. At that size the block encryption dominates the CPU time. > > Do you have measurements to support that? I'm quite surprized by such a > general statement because packetization itself is a non-negligible cost > especially when encryption is fast (i.e., in most modern CPUs with > dedicated instructions). > > regards, > Nikos > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11443834346d8f0541f3d2ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can you send multiple records in one data transfer to achi= eve whatever gains are desired?=C2=A0

<= div class=3D"gmail_quote">On Wed, Nov 23, 2016 at 12:30 AM, Nikos Mavrogian= nopoulos <nmav@redhat.com> wrote:
On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: > Hi, Nikos
>
> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos <nmav@redhat.com>
> wrote:
>
> >
> > Hi,
> > =C2=A0Up to the current draft of TLS1.3 the record layer is restr= icted
> > to
> > sending 2^14 or less. Is the 2^14 number something we want to
> > preserve?
> > 16kb used to be a lot, but today if one wants to do fast data
> > transfers
> > most likely he would prefer to use larger blocks. Given that the<= br> > > length
> > field allows for sizes up to 2^16, shouldn't the draft allow = for
> > 2^16-
> > 1024 as maximum?
>
> I am not opposed to this, but looking at real browsers and servers, > we see that they tend to set the size of records to fit IP packets.
IP packets can carry up to 64kb of data. I believe you may be referr= ing
to ethernet MTU sizes. That to my understanding is a way to reduce
latency in contrast to cpu costs. An increase to packet size targets
bandwidth rather than latency (speed).

> The gains from increasing the size of records from the ~1460 bytes
> that fit in a packet to nearly 64KB are not all that great, and the > gains from increasing records from 16 KB to 64KB are almost
> negligible. At that size the block encryption dominates the CPU time.<= br>
Do you have measurements to support that? I'm quite surprized by= such a
general statement because packetization itself is a non-negligible cost
especially when encryption is fast (i.e., in most modern CPUs with
dedicated instructions).

regards,
Nikos

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a11443834346d8f0541f3d2ee-- From nobody Wed Nov 23 00:41:05 2016 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 A6D19129634 for ; Wed, 23 Nov 2016 00:41:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 kGtK4bIFGgUF for ; Wed, 23 Nov 2016 00:41:03 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E31471293D8 for ; Wed, 23 Nov 2016 00:41:03 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id AA30C804F5; Wed, 23 Nov 2016 08:41:03 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.184]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAN8f1GT024870 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Nov 2016 03:41:02 -0500 Message-ID: <1479890461.2563.20.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Judson Wilson Date: Wed, 23 Nov 2016 09:41:01 +0100 In-Reply-To: References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Wed, 23 Nov 2016 08:41:03 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:41:05 -0000 On Wed, 2016-11-23 at 00:39 -0800, Judson Wilson wrote: > Can you send multiple records in one data transfer to achieve > whatever gains are desired?  The packetization cost still remains even if you do that. However, the question is how does the 2^14 limit comes from, and why TLS 1.3 should keep it? regards, Nikos From nobody Wed Nov 23 00:46:39 2016 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 6D067129634 for ; Wed, 23 Nov 2016 00:46:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oTCoQhU9MnAz for ; Wed, 23 Nov 2016 00:46:37 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (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 4BC5D1293E8 for ; Wed, 23 Nov 2016 00:46:37 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id f82so12629991wmf.1 for ; Wed, 23 Nov 2016 00:46:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+guC7L9uyYM3yLg6xRXOlruB7u91hNUZ0NCKjFBavMs=; b=sA3pYTfkN7j6fTdX+H2zaba16AmgwaHxLrDIgMlvyLKmD3ltdi92hPRx4En0y+BA3p 9NV9geWy0XFdz/o5lgHTvuZ0bftFRGEVwDTecuPhZ13svveOSIIROibla3mfNNlJDg8y KGZ2wgNJQpzhw8gmMm7zcw3nAVaYIxK2XliOCSTKKcdHjFw6Y3Z9r0aOhf1xnnwD79Ax /z2AAXwDrGEdZbsNB+oiiP+b/bL6BNKLGNiyQt7QdhcnJLok+Hwif56YC3BBhqesyf35 vrVIbiWLCidhoRjn+vmFdOQSRes9Wl3mgb+Rhpq8O4C93w2pz70xxkaBhjdKc3OBcxqS eSdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+guC7L9uyYM3yLg6xRXOlruB7u91hNUZ0NCKjFBavMs=; b=VrozXmIOYzNm+TIx0EZqZx2VkNgtYDT4Z9saI63uxe7LCmyDc0Le30f2kgHRuABNAP HiKHonLwRPRieSpWl1HrSFDPKlzJWFZDtlUyLV4seHLmd23KB+0gh7ntsUQQScrMu3B5 h1xQ41Ytba1LcrSVQ5+pIgSae7rwxyw3ywFpXOfDkAOEDDXbwjwQUtB/pc/IIQjQvCRW 3OJnc35WzCKlPn8BXIh1qBdPbYz1+LXTqUrFzm93ZPWBGWq/98z6yFF/X3E0UCJaKj6g OhPQJ/0rMsRpvW8eMF2+VL9Zgl1ToLDpcgoM3Pt7OkXUXHWc6X/8HuGoGUwEL+UljSzZ EVUw== X-Gm-Message-State: AKaTC01977g8rjIATpWThA5OmMTn6ILC4+6tnAEFCZxr/jzv2KtuTJJnnL21ZXk8ctk2O7UVmgBRTioGo0jSwg== X-Received: by 10.28.4.200 with SMTP id 191mr2068716wme.23.1479890795886; Wed, 23 Nov 2016 00:46:35 -0800 (PST) MIME-Version: 1.0 Received: by 10.80.168.133 with HTTP; Wed, 23 Nov 2016 00:46:35 -0800 (PST) In-Reply-To: <1479890461.2563.20.camel@redhat.com> References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <1479890461.2563.20.camel@redhat.com> From: Judson Wilson Date: Wed, 23 Nov 2016 00:46:35 -0800 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=001a1141fa263200dd0541f3ed6d Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:46:38 -0000 --001a1141fa263200dd0541f3ed6d Content-Type: text/plain; charset=UTF-8 I worry about the buffer sizes required on embedded devices. Hopefully the other endpoint would be programmed to limit record sizes, but is that something we want to rely on? This could be a parameter agreed upon during the handshake, but that seems bad. On Wed, Nov 23, 2016 at 12:41 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2016-11-23 at 00:39 -0800, Judson Wilson wrote: > > Can you send multiple records in one data transfer to achieve > > whatever gains are desired? > > The packetization cost still remains even if you do that. However, the > question is how does the 2^14 limit comes from, and why TLS 1.3 should > keep it? > > regards, > Nikos > > --001a1141fa263200dd0541f3ed6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I worry about the buffer sizes required on embedded d= evices. Hopefully the other endpoint would be programmed to limit record si= zes, but is that something we want to rely on?=C2=A0 This could be a parame= ter agreed upon during the handshake, but that seems bad.

On W= ed, Nov 23, 2016 at 12:41 AM, Nikos Mavrogiannopoulos <= ;nmav@redhat.com&g= t; wrote:
On Wed,= 2016-11-23 at 00:39 -0800, Judson Wilson wrote:
> Can you send multiple records in one data transfer to achieve
> whatever gains are desired?=C2=A0

The packetization cost still remains even if you do that. However, t= he
question is how does the 2^14 limit comes from, and why TLS 1.3 should
keep it?

regards,
Nikos


--001a1141fa263200dd0541f3ed6d-- From nobody Wed Nov 23 00:50:45 2016 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 6EE9F129634 for ; Wed, 23 Nov 2016 00:50:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d2cVocxobHwu for ; Wed, 23 Nov 2016 00:50:43 -0800 (PST) Received: from mail-wm0-x231.google.com (mail-wm0-x231.google.com [IPv6:2a00:1450:400c:c09::231]) (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 5FF211293E8 for ; Wed, 23 Nov 2016 00:50:42 -0800 (PST) Received: by mail-wm0-x231.google.com with SMTP id g23so67265118wme.1 for ; Wed, 23 Nov 2016 00:50:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0ByTaNT6O4dKbGsTRdnKb+kJAlTsmifTu1/AR+x5knQ=; b=1GCpS9Iofbv+kSihuDIe49NrFUFr7GgPYvFCOVTn28OJuU85JMBnmnR5vJ4QpLEArs epZ4ImZwkSDOFveL29moZNT2p4gicGsdrjlIonKVBa8EpBgWTL7LBCX07YVEasDbdILZ tuLinRS+6uEJL+jQMH0J6J8k5LXMmkdPjt+3QMbf5HfPQ9TNUjzTgYOxv0OO9F5Yuq+V uYBQYPQ5e4q2gWBEGs70v1o7UG9cCz/F2ZHp94NVk0TIqHdif1ldkcvetYi/JL1hFfY8 g9TIy4Dwj2Hsq5PMa80biX6Vkv1UVDsyAwhxg5Xuc/ei6d8yevao+6gGFRhXv7x09TP3 vIug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0ByTaNT6O4dKbGsTRdnKb+kJAlTsmifTu1/AR+x5knQ=; b=d+dH+Egwnj0zaDqU+Vf6/8RbeYkV9hrl4jhoI5SYMEhBkCHg65+7uAdJk4mBAg+xUT VUcdQE/CyZsYAKxwHhx7ul0ankNpUGTqNFk7HOLkEjmEwF8NaHSzUHEjpps1GDPJgFhy gan/sq9s0yT84VAFY+HV2FzpegaYi6cehdbA8oNtc5LghQvTir3E1Xx+zyyaFcdrwOe4 RlU72kpeb4GNG1Y8BcpU6tdCXxCShwEJqC4jRt6Mwfo3MCS4dNIsmBdykr1vRQSnykbL 3mD63sU+FEmesxD4PIdinpAc5QJ3Ur3Z/dORhCQbc5zpXuD87PuXRfh5xlkxFATU4qt3 g7yQ== X-Gm-Message-State: AKaTC01ineWtqVuQ7uSWyU4PqVIwaCr974qgwejJSIE82LT1KtILpMNdBv2lDcY2Yx4PGA== X-Received: by 10.28.16.70 with SMTP id 67mr2061586wmq.53.1479891040870; Wed, 23 Nov 2016 00:50:40 -0800 (PST) Received: from [172.24.250.223] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id a13sm1531222wma.18.2016.11.23.00.50.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 00:50:40 -0800 (PST) From: Yoav Nir Message-Id: <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_5D5E238C-4311-4D01-966E-DD0C5B8587A5" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Wed, 23 Nov 2016 10:50:37 +0200 In-Reply-To: <1479889806.2563.15.camel@redhat.com> To: Nikos Mavrogiannopoulos References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:50:44 -0000 --Apple-Mail=_5D5E238C-4311-4D01-966E-DD0C5B8587A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos = wrote: > On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >> Hi, Nikos >>=20 >> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos >> wrote: >>=20 >>>=20 >>> Hi, >>> Up to the current draft of TLS1.3 the record layer is restricted >>> to >>> sending 2^14 or less. Is the 2^14 number something we want to >>> preserve? >>> 16kb used to be a lot, but today if one wants to do fast data >>> transfers >>> most likely he would prefer to use larger blocks. Given that the >>> length >>> field allows for sizes up to 2^16, shouldn't the draft allow for >>> 2^16- >>> 1024 as maximum? >>=20 >> I am not opposed to this, but looking at real browsers and servers,=20= >> we see that they tend to set the size of records to fit IP packets.=20= >=20 > IP packets can carry up to 64kb of data. I believe you may be = referring > to ethernet MTU sizes. I=E2=80=99m referring to the IP packets that they actually use, and that = is set by TCP to fit the PMTU, which is <=3D the ethernet MTU. In = practice it is 1500 bytes for most network paths. > That to my understanding is a way to reduce > latency in contrast to cpu costs. An increase to packet size targets > bandwidth rather than latency (speed). Sure, but running =E2=80=98openssl speed=E2=80=99 on either aes-128-cbc = or hmac or sha256 (there=E2=80=99s no test for AES-GCM or ChaCha-poly) = you get smallish differences in terms of kilobytes per second between = 1024-byte buffers and 8192-byte buffers. And the difference going to be = even smaller going to 16KB buffers, let alone 64KB buffers. >> The gains from increasing the size of records from the ~1460 bytes >> that fit in a packet to nearly 64KB are not all that great, and the >> gains from increasing records from 16 KB to 64KB are almost >> negligible. At that size the block encryption dominates the CPU time. >=20 > Do you have measurements to support that? I'm quite surprized by such = a > general statement because packetization itself is a non-negligible = cost > especially when encryption is fast (i.e., in most modern CPUs with > dedicated instructions). As long as you run over a network that has a smallish MTU, you=E2=80=99re = going to incur the packetization costs anyway, either in your code or in = operating system code. If you have a 1.44 GB file you want to send, = it=E2=80=99s going to take a million IP packets either way and 100 = million AES block operations.=20 Whether you do the encryption is a million 1440-byte records or 100,000 = 14,400-byte records makes a difference of only a few percent. Measurement that we=E2=80=99ve made bear this out. They=E2=80=99re with = IPsec, so it=E2=80=99s fragmentation rather than packetization, but I = don=E2=80=99t think that should make much of a difference. Again, I=E2=80=99m not opposed to this. A few percent is a worthy gain. Yoav --Apple-Mail=_5D5E238C-4311-4D01-966E-DD0C5B8587A5 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 23 Nov 2016, at 10:30, = Nikos Mavrogiannopoulos <nmav@redhat.com> wrote:

On Wed, 2016-11-23 at 10:05 +0200, Yoav = Nir wrote:
Hi, Nikos

On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos <nmav@redhat.com>
wrote:


Hi,
 Up to the current = draft of TLS1.3 the record layer is restricted
to
sending 2^14 or less. Is the 2^14 number something we want = to
preserve?
16kb used to be a lot, but = today if one wants to do fast data
transfers
most likely he would prefer to use larger blocks. Given that = the
length
field allows for sizes up to = 2^16, shouldn't the draft allow for
2^16-
1024= as maximum?

I am not opposed = to this, but looking at real browsers and servers, 
we see that = they tend to set the size of records to fit IP packets. 

IP packets can carry up to 64kb of data. = I believe you may be referring
to ethernet MTU sizes. =

I=E2=80=99m = referring to the IP packets that they actually use, and that is set by = TCP to fit the PMTU, which is <=3D the ethernet MTU.  In = practice it is 1500 bytes for most network paths.

That to my understanding is a way to = reduce
latency in contrast to cpu costs. An increase to = packet size targets
bandwidth rather than latency = (speed).

Sure, but = running =E2=80=98openssl speed=E2=80=99 on either aes-128-cbc or hmac or = sha256 (there=E2=80=99s no test for AES-GCM or ChaCha-poly) you get = smallish differences in terms of kilobytes per second between 1024-byte = buffers and 8192-byte buffers. And the difference going to be even = smaller going to 16KB buffers, let alone 64KB buffers.

The gains from increasing = the size of records from the ~1460 bytes
that fit in a = packet to nearly 64KB are not all that great, and the
gains = from increasing records from 16 KB to 64KB are almost
negligible. At that size the block encryption dominates the = CPU time.

Do you have measurements to = support that? I'm quite surprized by such a
general statement because packetization itself = is a non-negligible cost
especially when encryption is fast (i.e., = in most modern CPUs with
dedicated instructions).

As long as = you run over a network that has a smallish MTU, you=E2=80=99re going to = incur the packetization costs anyway, either in your code or in = operating system code. If you have a 1.44 GB file you want to send, = it=E2=80=99s going to take a million IP packets either way and 100 = million AES block operations. 

Whether you do the encryption is a = million 1440-byte records or 100,000 14,400-byte records makes a = difference of only a few percent.

Measurement that we=E2=80=99ve made = bear this out. They=E2=80=99re with IPsec, so it=E2=80=99s fragmentation = rather than packetization, but I don=E2=80=99t think that should make = much of a difference.

Again, I=E2=80=99m not opposed to this. A few percent is a = worthy gain.

Yoav

= --Apple-Mail=_5D5E238C-4311-4D01-966E-DD0C5B8587A5-- From nobody Wed Nov 23 00:51:02 2016 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 3D5A41296A5 for ; Wed, 23 Nov 2016 00:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mZ9gfovmKYOH for ; Wed, 23 Nov 2016 00:50:50 -0800 (PST) Received: from smtp.ssi.gouv.fr (smtp.ssi.gouv.fr [86.65.182.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15B911296A0 for ; Wed, 23 Nov 2016 00:50:49 -0800 (PST) Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id 47FA490B930; Wed, 23 Nov 2016 09:50:48 +0100 (CET) To: Eric Rescorla References: <20161122190158.GB19978@neoplankton.picty.org> From: Olivier Levillain X-Enigmail-Draft-Status: N1110 Message-ID: <58355868.5050506@ssi.gouv.fr> Date: Wed, 23 Nov 2016 09:50:48 +0100 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Extensions and message reuse X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:51:00 -0000 Le 22/11/2016 22:19, Eric Rescorla a écrit : > On Tue, Nov 22, 2016 at 11:02 AM, Olivier Levillain < > olivier.levillain@ssi.gouv.fr> wrote: >> The first example of such a problem is the signature_scheme and >> signature_algorithms enums. In practice, the signature_algorithm must >> contain information valid for TLS 1.2 and TLS 1.3, but the exact >> meaning is not the same in both cases. It would be cleaner to have a >> new, separate extension called signature_scheme, defining the new >> enum. This way, a TLS 1.2/1.3 client implementations would send both >> extensions. We would spend 10 bytes on the wire, but it is not that >> important for the first message which can be kept reasonably long >> (and which is sometimes padded via the corresponding extension...) >> > We certainly could do this, but I don't think it's the right answer, for > two reasons: > > 1. From a protocol perspective, some of the things you could say with > signature_algorithms weren't coherent. For instance: I support ECDSA_SHA512 > but only with P256 (via supported_curves). So it's actually a retroactive > improvement to TLS 1.2 to use the code points this way. NSS, at least > interprets these the same way in TLS 1.2 and TLS 1.3. I believe BoringSSL > does as well. > 2. From an implementation perspective, it's easier to just have a single > external facing surface, which should be the more sensible one, namely > signature schemes. I understand your point, but there were different curves with the same security parameter in TLS 1.2, and advertising some combinations in a TLS 1.2 / 1.3 (supporting Brainpool curves but not the NIST equivalent) implementation might be a pain. Considering the current deployment, we certainly can live with that. We also were wondering why not reuse the values for hash algorithms for PSS: if we use 0x04XX for PSS-sha256 and 0x05XX for PSS-sha384, etc. it would align with existing TLS 1.2 behaviour, and make it easier to include PSS support in these implementations, as is recommended by the specification. >> Another example is the key_share extension: it is in fact made of >> three different extensions, depending on the message where it is >> included. It would be simpler for a (almost-)stateless parser* to >> either use three different extensions or to use the same content each >> time. In the second case, the extension would each time consist of a >> list of (group + optional keyshare). The advantages of such a unified >> keyshare extension would be: >> - stateless parsing* >> - no reuse of supported_groups which can be merged with key_share >> - no more validation complexity since higher-level checks were >> already required (the groups sent by HRR did not came with a key >> share for example). >> The major con one might see is that the server can not advertise its >> supported groups in an encrypted manner anymore (since >> supported_groups is not used anymore). However, we do believe >> simplifying the implementation is worth it. >> >> * Of course the parser still has to use the extension id to know how >> to parse the value, but it would not need to have broader context >> (the message where the extension is included). In other words, we >> would like select syntax in structs to only use local information. >> >> I can try and propose a PR for each extension if there is an interest >> in the WG. >> > It seems to me you are making two points here: > > 1. That it would be good to unify supported_groups and key_share > 2. That we should use separate code points wherever extensions differ > between the messages they appear (this is far from the only one). > > We've had some conversation about the first approach, which seems like kind > of a stylistic/taste issue whether to have the "I can do" and "here is" in > one > place or two, and on balance I think it's better to not change this at this > point > without a really compelling reason. I have no compelling reason, but I don't remember why the WG chose to stick with two extensions where there was a working design with only one. > I can see the appeal of having one parser per extension ID, but it isn't > actually that much easier from an implementation perspective. You already > need a mapping table from extension ID to handler and that table > also needs to be able to detect common problems (e.g., extension reuse > or extensions appearing in the wrong place) and it's not hard at that > point to also have it point to message-specific parsers (this is how NSS > mostly works). ISTM that the alternative you propose would either result > in a proliferation of extensions (which confuses the matching rules) > or having extensions which are syntactically valid but not legal in > their context (e.g., >1 key share from the server). This pushes these > checks further away from the decoder, and makes things which would > otherwise be syntax errors (e.g., a "pre_shared_key" extension from > the server which contains keys) into semantic errors which require > explicit checks. I understand your point of view (and we know that key_share is not the only extension with this property) and this can be expressed rather easily in code. (However, it is important to remember that there must still be checks to implement at the semantic level when receiving this extension, as explained in the spec: - HRR: check that the group was not proposed in the first place in keyshare (but that it is supported) - Second CH: check that there is only one key share matching the required group - SH: check that the key share matches one of the group sent in the CH) olivier From nobody Wed Nov 23 00:53:35 2016 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 CF394129634 for ; Wed, 23 Nov 2016 00:53:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 0zMU7EZrPZYG for ; Wed, 23 Nov 2016 00:53:32 -0800 (PST) Received: from smtp.ssi.gouv.fr (smtp.ssi.gouv.fr [86.65.182.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 919761294C5 for ; Wed, 23 Nov 2016 00:53:32 -0800 (PST) Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id 4104C90B933; Wed, 23 Nov 2016 09:53:31 +0100 (CET) To: Martin Thomson References: <20161122190720.GE19978@neoplankton.picty.org> From: Olivier Levillain Message-ID: <5835590B.2010400@ssi.gouv.fr> Date: Wed, 23 Nov 2016 09:53:31 +0100 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:53:34 -0000 Le 23/11/2016 01:28, Martin Thomson a écrit : > On 23 November 2016 at 06:07, Olivier Levillain > wrote: >> In 4.2.8 (P.47), the server receiving early_data "can behave in one of >> two ways"... followed by three cases. Beside the typo, the first case >> could be phrased differently. Actually, it reads >> >> - Ignore the extension and return no response. This indicates that >> the server has ignored any early data and an ordinary 1-RTT >> handshake is required. >> >> Since an ordinary 1-RTT handshake will require the server to actually >> send a response (the ServerHello), it might be better to put it this >> way: >> >> - Ignore the extension and return a standard 1-RTT ServerHello. >> This indicates that the server has ignored any early data and >> an ordinary 1-RTT handshake is required. > Here's a PR: https://github.com/tlswg/tls13-spec/pull/773 > > I've gone a little bit further than what Olivier suggests and pointed > out in each of these that the server is required to ignore early data. Thank you for the rewrite. olivier From nobody Wed Nov 23 00:54:04 2016 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 3E67512966F for ; Wed, 23 Nov 2016 00:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoLB3_6YnDD5 for ; Wed, 23 Nov 2016 00:53:54 -0800 (PST) Received: from mail-wj0-x232.google.com (mail-wj0-x232.google.com [IPv6:2a00:1450:400c:c01::232]) (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 70A901293E8 for ; Wed, 23 Nov 2016 00:53:54 -0800 (PST) Received: by mail-wj0-x232.google.com with SMTP id qp4so5200503wjc.3 for ; Wed, 23 Nov 2016 00:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=9yZdSkEqFQklSviixsauHpgrE/EYcE3zlDbrP0smw2k=; b=iaEzCfYMB1QUlLKkeJ9fHm1rOZ/M5Lb90MngF39ZyXeHRKxfqhs//vDi5YsEk1GUdd 7ZlZoCM1Hn8PtsO7KYlJlhIoCAxeJZhaHCVaohoYLXChiYGj5jSseVoWeCjYYV8wYiTO J0lw4s+Hn5WDJQ5gtu/D4M5GAUAmGoHu2+yHSHDj+lTaerkMGGSR7mCfUEq72POzClaL CDw7hmWxk1ksCgCqv6C5Unb/6ICCwuqn6uka27/oN0NwTIsRRfGOYsgVxXY/whSYhHby kgF4fxDQz6CMpimvtm26MN3Vrxn5LIQlelN2zDxhxFHDu0C8Xzc12/IhQSgwRtY1NIQy GuXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=9yZdSkEqFQklSviixsauHpgrE/EYcE3zlDbrP0smw2k=; b=Ae791v7m3s4unKpV2bhGe3meWQEqdT3HIa+UT9loOwywPvUjJuYb71bQvOxilRenWI Jb0xIBz697sH0oL4pNvXzcPW8zYw7kV1UdXlzrIpcB5OXSQ976JRpTh5qCVyuPZV7/D7 72QhK2eXQ1tFQUf5MkxzhZaCjkq87cOcRBCpPhMHdKh4zkXwJrMOlcmwYo+j2RZIXdHt KYixvrBlBn9IF/LKPfLDrvOVzL/kBaKZ60ICo9R+kzcowsScOdGsaLuMMWbuaj+JxlQG Gsk7WVIgX6DgzrV4OYvrlEu22ScL+pPSB7ZsWZ5EikGncgbeHOhu1jMJ9lp+rnXkpbti KOjQ== X-Gm-Message-State: AKaTC01AfaNBwxNF/3qi4lvFCqsqQjtj0dnKXlnc3Z0JFU3wFnpW2qbial4/q91JWUqcwA== X-Received: by 10.194.145.70 with SMTP id ss6mr2439987wjb.158.1479891232745; Wed, 23 Nov 2016 00:53:52 -0800 (PST) Received: from [172.24.250.223] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id u18sm1580338wmd.1.2016.11.23.00.53.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 00:53:52 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Wed, 23 Nov 2016 10:53:51 +0200 References: <4DF30312-1A1C-4F11-9424-0412E5A52E6B@gmail.com> To: "" In-Reply-To: <4DF30312-1A1C-4F11-9424-0412E5A52E6B@gmail.com> Message-Id: X-Mailer: Apple Mail (2.3251) Archived-At: Subject: Re: [TLS] Re-use and export of DH shares X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 08:53:58 -0000 And if it wasn=E2=80=99t clear, this *is* a WGLC comment on the TLS 1.3 = draft based on discussion in Tuesday=E2=80=99s session in Seoul. Yoav > On 20 Nov 2016, at 12:21, Yoav Nir wrote: >=20 > Hi. >=20 > I=E2=80=99ve created a PR for TLS 1.3 > https://github.com/tlswg/tls13-spec/pull/768 >=20 > It adds a subsection to the Security Considerations section. It = discusses key reuse (do it carefully or do it not). > It has the "don't do this or this grape juice might ferment" weasel = words suggested by someone at the meeting. >=20 > Yoav >=20 From nobody Wed Nov 23 01:03:36 2016 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 8C02312963A for ; Wed, 23 Nov 2016 01:03:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 tZkOBstEK0EI for ; Wed, 23 Nov 2016 01:03:33 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F051295B5 for ; Wed, 23 Nov 2016 01:03:33 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id C361388E60; Wed, 23 Nov 2016 09:03:32 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.2.184]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAN93Ura004874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 23 Nov 2016 04:03:32 -0500 Message-ID: <1479891810.2563.30.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Judson Wilson Date: Wed, 23 Nov 2016 10:03:30 +0100 In-Reply-To: References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <1479890461.2563.20.camel@redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.27 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.25]); Wed, 23 Nov 2016 09:03:32 +0000 (UTC) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 09:03:34 -0000 Maybe a solution would be a better maximum fragment length extension which allows the size can be negotiated in a more fine-grained way, as pointed in: https://www.ietf.org/mail-archive/web/tls/current/msg12472.html I also found these requests asking for larger packet sizes. https://www.ietf.org/mail-archive/web/tls/current/msg13569.html https://mailarchive.ietf.org/arch/msg/tls/K_6Ug4GtAxbrQJy2CFFFoxxtJ60 On Wed, 2016-11-23 at 00:46 -0800, Judson Wilson wrote: > I worry about the buffer sizes required on embedded devices. > Hopefully the other endpoint would be programmed to limit record > sizes, but is that something we want to rely on?  This could be a > parameter agreed upon during the handshake, but that seems bad. > > > On Wed, Nov 23, 2016 at 12:41 AM, Nikos Mavrogiannopoulos t.com> wrote: > > On Wed, 2016-11-23 at 00:39 -0800, Judson Wilson wrote: > > > Can you send multiple records in one data transfer to achieve > > > whatever gains are desired?  > > > > The packetization cost still remains even if you do that. However, > > the > > question is how does the 2^14 limit comes from, and why TLS 1.3 > > should > > keep it? > > > > regards, > > Nikos From nobody Wed Nov 23 01:08:39 2016 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 F3A841295B5 for ; Wed, 23 Nov 2016 01:08:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 mNzSbEd3ojLR for ; Wed, 23 Nov 2016 01:08:36 -0800 (PST) Received: from smtp.ssi.gouv.fr (smtp.ssi.gouv.fr [86.65.182.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57D8E12945B for ; Wed, 23 Nov 2016 01:08:36 -0800 (PST) Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id EF3B890B920; Wed, 23 Nov 2016 10:08:34 +0100 (CET) To: Eric Rescorla , David Benjamin References: <20161122190822.GH19978@neoplankton.picty.org> From: Olivier Levillain X-Enigmail-Draft-Status: N1110 Message-ID: <58355C92.8070504@ssi.gouv.fr> Date: Wed, 23 Nov 2016 10:08:34 +0100 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Message splitting and interleaving X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 09:08:38 -0000 Le 23/11/2016 00:24, Eric Rescorla a écrit : > On Tue, Nov 22, 2016 at 2:18 PM, David Benjamin > wrote: > >> On Tue, Nov 22, 2016 at 2:05 PM Olivier Levillain < >> olivier.levillain@ssi.gouv.fr> wrote: >> >>> Hi list, >>> >>> I am sorry for the very late answer concerning draft 18, but we >>> (ANSSI) have several remarks after proof-reading the current >>> specification. >>> >>> We are sorry for the multiple long messages. >>> >>> If the WG is interested by some of our concerns/proposals, we would be >>> glad to propose some PRs. >>> >>> >>> = Message splitting and interleaving = >>> >>> How to split and interleave subprotocols in TLS has not been clearly >>> specified in the past, and it would be useful to be crystal clear on >>> this point. >>> >>> In the specification, the subject is first presented in 4.5 (P.61): >>> Handshake messages sent after the handshake MUST NOT be interleaved >>> with other record types. That is, if a message is split over two or >>> more handshake records, there MUST NOT be any other records between >>> them. >>> But I am wondering why this text only concern "messages after the >>> handshake". It should always be the case! I don't know what is your take on this first point, but I think I will propose something in the PR. I will try to add/move some text so the information is all present in section 5. >> +1. We (BoringSSL) and I believe NSS already forbid this for alerts at all >> versions. >> >> This rule is actually implied by TLS 1.3 already, because we've gotten rid >> of warning alerts. All alerts terminate the connection, except for >> end_of_early_data, and end_of_early_data immediately signals a key change. >> So it is not legal to send two alerts in the same epoch, much less in the >> same record. (Being explicit about this is good, of course.) >> > This seems fine. I would take a PR for this. Will do. > - incidentally, the default behaviour would apply to Heartbeat, as >>> was the intent of the specification; >>> - ApplicationData should be considered as a stream with possibly >>> 0-length records >>> - Handshake messages should either come as a sequence of multiple >>> *entire* messages, or as a fraction of *one* message. That is, >>> the number of HS messages inside one record should either be a >>> round number or strictly less than 1. >>> >> What simplifications were you expecting out of this? It seems to me this >> would be a nuisance to both enforce as a receiver and honor as a sender. >> >> Our implementation doesn't try to pack handshake messages into records, >> but I believe NSS does. NSS folks should confirm, but I expect such >> implementations just buffer the messages up and flush when the buffer >> exceeds the records size. That means all kinds of splits are plausible: >> >> [EncryptedExtensions Certifi] >> [cateRequest Certificate Cer] >> [tificateVerify Finished] >> > Yeah, that's how this works in NSS. > > I'm not seeing a real benefit in prohibiting this behavior. The expected benefit was that it was a way to enforce the rule from section 4.6 (P.64), stating that a Handshake message should not span key changes. That is why the receiver already had to do some work, and my proposal was to restrict it even more. Yet I see your point that from the sender's point of view, this is more complex. After re-reading the 4.6 part, I find it sufficient. Sorry for the noise about this. olivier From nobody Wed Nov 23 02:15:13 2016 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 1B105129BE8 for ; Wed, 23 Nov 2016 02:15:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 JB_KLCBRdz_r for ; Wed, 23 Nov 2016 02:15:10 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21519129BE3 for ; Wed, 23 Nov 2016 02:15:09 -0800 (PST) X-AuditID: c1b4fb3a-d644398000007918-f0-58356c2c190e Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by (Symantec Mail Security) with SMTP id 4B.5A.31000.C2C65385; Wed, 23 Nov 2016 11:15:08 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.62]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 11:15:06 +0100 From: John Mattsson To: Sean Turner , "" Thread-Topic: [TLS] WGLC for draft-ietf-tls-rfc4492bis Thread-Index: AQHSQh6ZBtLjySIXQkGGsA9kkiXhRqDmYMOA Date: Wed, 23 Nov 2016 10:15:06 +0000 Message-ID: References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> In-Reply-To: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: <875A82C46116B044A948F35966232B4F@ericsson.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnkeLIzCtJLcpLzFFi42KZGbFdV1cnxzTC4OcBIYsrqxqZLT6d72J0 YPJYsuQnk8fBg4wBTFFcNimpOZllqUX6dglcGX/udDEVzFOv2PmPpYFxjloXIyeHhICJxLRV L1m7GLk4hATWMUosX7mFHcJZzCgx5fFeRpAqNgEDibl7GthAbBEBR4ljtyeA2cICphKfXvWx QsTNJDZtnQvUzAFkG0ls22oDEmYRUJX4d303O4jNK2Au8W72VbCRQgI2Ep27loDFOQVsJSav P8cEYjMKiEl8P7UGzGYWEJe49WQ+E8ShAhJL9pxnhrBFJV4+/scKskpUQE9izf0wiLCixNXp y5lAwswCmhLrd+lDTLGW2Pb2IguErSgxpfsh1DWCEidnPmGZwCg2C8myWQjds5B0z0LSPQtJ 9wJG1lWMosWpxcW56UZGeqlFmcnFxfl5enmpJZsYgdF0cMtvqx2MB587HmIU4GBU4uEtiDWJ EGJNLCuuzD3EKMHBrCTC65htGiHEm5JYWZValB9fVJqTWnyIUZqDRUmc12zl/XAhgfTEktTs 1NSC1CKYLBMHp1QDY0RqV2iv7IRPu1dzKUUe9bU2bp72jE3kaMXMk0/5mjMzhZ5vfSHGeUNh ybrzmyWm34tnXxVv53opnn3bMoXrHpMPzrPXnjbhsn/l/g2PZn5/W7ixbl/H5DvRXZL/Uqe0 f+puerlk4oevP+KyolbeeGN3iNUySZXJoXrVb3aTeQcKtjjP9r4Ut1CJpTgj0VCLuag4EQBt WWPEogIAAA== Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 10:15:12 -0000 SSBoYXZlIG5vdCByZWFkIHRoZSBwcm9jZXNzaW5nIHBhcnRzIGluIGRldGFpbC4gSGVyZSBhcmUg Y29tbWVudHMgb24gdGhlDQpmaXJzdCBhbmQgbGFzdCBzZWN0aW9ucyBvZiB0aGUgZG9jdW1lbnQu DQoNCkNoZWVycywNCkpvaG4NCg0KLSBTb21ld2hlcmUNCkkgc3VnZ2VzdCBhZGRpbmcgdGhlIGZv bGxvd2luZyBzZW50ZW5jZSBmcm9tIFRMUyAxLjM6DQoiQXBwbGljYXRpb25zIFNIT1VMRCBhbHNv IGVuZm9yY2UgbWluaW11bSBhbmQgbWF4aW11bSBrZXkgc2l6ZXMuICBGb3INCmV4YW1wbGUsIGNl cnRpZmljYXRpb24gcGF0aHMgY29udGFpbmluZyBrZXlzIG9yIHNpZ25hdHVyZXMgd2Vha2VyIHRo YW4NCjIwNDgtYml0IFJTQSBvciAyMjQtYml0IEVDQyBhcmUgbm90IGFwcHJvcHJpYXRlIGZvciBz ZWN1cmUgYXBwbGljYXRpb25zLiINCg0KVGhpcyBpcyBhcyB0cnVlIGZvciBUTFMgMS4wLCAxLjEs IGFuZCAxLjIgYXMgZm9yIFRMUyAxLjMNCg0KLSBTZWN0aW9uIDENCiJDb21wYXJlZCB0byBjdXJy ZW50bHkgcHJldmFsZW50IGNyeXB0b3N5c3RlbXMgc3VjaCBhcyBSU0EsIEVDQyBvZmZlcnMiDQoN CkkgdGhpbmsgdGhpcyBzaG91bGQgYmUgdXBkYXRlZCwgRUNESEUgaXMgYWxyZWFkeSB2ZXJ5IHdl bGwtc3ByZWFkLg0KDQotIFNlY3Rpb24gMQ0KIlRoaXMgaXMgaWxsdXN0cmF0ZWQgaW4gdGhlIGZv bGxvd2luZyB0YWJsZSwgYmFzZWQgb24gW0xlbnN0cmFfVmVyaGV1bF0sDQp3aGljaCBnaXZlcyBh cHByb3hpbWF0ZSBjb21wYXJhYmxlIGtleSBzaXplcyBmb3Igc3ltbWV0cmljLSBhbmQNCmFzeW1t ZXRyaWMta2V5IGNyeXB0b3N5c3RlbXMgYmFzZWQgb24gdGhlIGJlc3Qta25vd24gYWxnb3JpdGht cyBmb3INCmF0dGFja2luZyB0aGVtLiINCg0KVGhlIGtleSBzaXplcyBmb3IgREgvRFNBL1JTQSBk b2VzIG5vdCBzZWVtIHRvIGJlIGJhc2VkIG9uIHRoZQ0KTGVuc3RyYS1WZXJoZXVscyBlcXVhdGlv bnMgd2hpY2ggZ2l2ZXMgbXVjaCBoaWdoZXIga2V5IHNpemVzIGZvcg0KREgvRFNBL1JTQS4NCg0K VGhlIERIL0RTQS9SU0Ega2V5IHNpemVzIHNlZW0gdG8gYmUgYmFzZWQgb24gTklTVCByZWNvbW1l bmRhdGlvbnMuIEkNCnN1Z2dlc3QgZWl0aGVyOg0KDQpBKSBGdWxseSBiYXNlZCB0aGUgdGFibGUg b24gTklTVCByZWNvbW1lbmRhdGlvbiwgd2hpY2ggbWVhbnMga2VlcGluZw0KREgvRFNBL1JTQSBh cyBpcyBidXQgc2ltcGxpZnlpbmcgRUNDIHRvIDIgKiBTeW1tZXRyaWMuDQpCKSBVcGRhdGUgdGhl IERIL0RTQS9SU0Ega2V5IHNpemVzIGJhc2VkIG9uIHN0YXRlLW9mLXRoZS1hcnQuIEJ1dCB0aGVu IEkNCndvdWxkIHNheSB0aGF0IHRoaXMgaXMgbm90IFtMZW5zdHJhX1ZlcmhldWxdLCBidXQgcmF0 aGVyIFtSRkMzNzY2XSwNCltMZW5zdHJhIDIwMDRdLCBbRUNSWVBUIDIwMTJdLiBJIHRoaW5rIHRo ZXNlIHRocmVlIGFsbCB1c2UgdGhlIHNhbWUNCmVxdWF0aW9uLg0KQykgSnVzdCByZW1vdmUgREgv RFNBL1JTQSBhcyB0aGUgZHJhZnQgaXMgYWJvdXQgRUNDLg0KDQotIFNlY3Rpb24gMg0KIkhvd2V2 ZXIsIHRoZSBjb21wdXRhdGlvbmFsIGNvc3QgaW5jdXJyZWQgYnkgYSBzZXJ2ZXIgaXMgaGlnaGVy IGZvcg0KRUNESEVfUlNBIHRoYW4gZm9yIHRoZSB0cmFkaXRpb25hbCBSU0Ega2V5IGV4Y2hhbmdl LCB3aGljaCBkb2VzIG5vdA0KcHJvdmlkZSBmb3J3YXJkIHNlY3JlY3kuIg0KDQpUcnVlLCBidXQg SSB0aGluayBpdCBnaXZlcyB0aGUgd3JvbmcgaW1wcmVzc2lvbi4gSSB0aGluayB0aGUgYWRkaXRp b25hbA0KY29zdCBpcyBuZWdsaWdpYmxlLiBJIGRvbid0IGhhdmUgYW55IFRMUyBiZW5jaG1hcmtz IGJ1dCBmb3IgaTUtNjYwMCwNCmJlbmNoLmNyLnlwLnRvIGdpdmVzOg0KDQpyb25hbGQzMDcyIGRl Y3J5cHQgIDg3NzY4NjQgY3ljbGVzDQoNCnJvbmFsZDMwNzIgc2lnbiAgICAgODc4MTg0MiBjeWNs ZXMNCmN1cnZlMjU1MTkga2V5Z2VuICAgIDE2MzIwMCBjeWNsZXMNCmN1cnZlMjU1MTkgY29tcHV0 ZSAgIDE2NTgxNiBjeWNsZXMNCg0KVGhhdCdzIG9ubHkgMy44JSBvdmVyaGVhZCBmb3IgY3J5cHRv LCBhbmQgbXVjaCBsZXNzIGlmIGNhbGN1bGF0ZWQgZm9yIHRoZQ0Kd2hvbGUgaGFuZHNoYWtlLiBJ IHN1Z2dlc3QgcmVtb3ZpbmcgdGhlIHNlbnRlbmNlLCBvciB3cml0aW5nIHRoYXQgdGhlDQphZGRp dGlvbmFsIHNlcnZlciBjb3N0IGZvciBmb3J3YXJkIHNlY3JlY3kgaXMgbmVnbGlnaWJsZSBhbmQg d2VsbCB3b3J0aCBpdC4NCg0KLSBTZWN0aW9uIDYNCiJUTFNfRUNESF9FQ0RTQV9XSVRIX0FFU18x MjhfQ0JDX1NIQTI1NiINCg0KU2hvdWxkIHRoaXMgYmUgIlRMU19FQ0RIRV9FQ0RTQV9XSVRIX0FF U18xMjhfQ0JDX1NIQTI1NiI/DQpJIGRvbid0IHRoaW5rIHRoZSBkb2N1bWVudCBzaG91bGQgcmVj b21tZW5kIHN1cHBvcnQgb2YgY2lwaGVyIHN1aXRlcw0Kd2l0aG91dCBmb3J3YXJkIHNlY3JlY3ku DQoNCi0gU2VjdGlvbiA3DQoiZG9jdW1lbXRzIiAtPiAiZG9jdW1lbnRzIg0KDQotIFNlY3Rpb24g Nw0KIk5FRUQgVE8gQUREIEEgUEFSQUdSQVBIIEhFUkUgQUJPVVQgV0hZIFgyNTUxOS9YNDQ4IEFS RSBQUkVGRVJSQUJMRSBUTw0KTklTVCBDVVJWRVMuIg0KDQpJIHN1Z2dlc3QgdXNpbmcgdGhlIGV4 Y2VsbGVudCBleHBsYW5hdGlvbiBpbiBSRkM3NzQ4IGFzIGEgYmFzaXMuDQpTdWdnZXN0aW9uOg0K DQoiTW9kZXJuIGN1cnZlcyBzdWNoIFgyNTUxOSBhbmQgWDQ0OCBbUkZDNzc0OF0gYXJlIHByZWZl cmFibGUgYXMgdGhleSBsZW5kDQp0aGVtc2VsdmVzIHRvIGNvbnN0YW50LXRpbWUgaW1wbGVtZW50 YXRpb24gYW5kIGFuIGV4Y2VwdGlvbi1mcmVlIHNjYWxhcg0KbXVsdGlwbGljYXRpb24gdGhhdCBp cyByZXNpc3RhbnQgdG8gYSB3aWRlIHJhbmdlIG9mIHNpZGUtY2hhbm5lbCBhdHRhY2tzLA0KaW5j bHVkaW5nIHRpbWluZyBhbmQgY2FjaGUgYXR0YWNrcy4gRm9yIG1vcmUgaW5mb3JtYXRpb24gc2Vl IFtTYWZlQ3VydmVzXS4iDQoNCltTYWZlQ3VydmVzXSAgaHR0cHM6Ly9zYWZlY3VydmVzLmNyLnlw LnRvLw0KDQotIFNlY3Rpb24gNw0KIlN1YnN0YW50aWFsIGFkZGl0aW9uYWwgaW5mb3JtYXRpb24g b24gZWxsaXB0aWMgY3VydmUgY2hvaWNlIGNhbiBiZSBmb3VuZA0KaW4gW0lFRUUuUDEzNjMuMTk5 OF0sIFtBTlNJLlg5LTYyLjIwMDVdLCBhbmQgW0ZJUFMuMTg2LTRdIi4NCg0KSSB0aGluayBpdCBp cyBiZXR0ZXIgdG8gcmVmZXIgcGVvcGxlIHRvIFtTYWZlQ3VydmVzXS4NCg0KLSBTZWN0aW9uIDcN ClRoZSBwYXJhZ3JhcGggYWJvdXQgc3RydWN0dXJlIGdpdmVzIHRoZSBpbXByZXNzaW9uIHRoYXQg IkZfcCB3aXRoIHANCnJhbmRvbSIgaXMgdGhlIG9wdGltYWwgY2hvaWNlLiBJIHRoaW5rIHRoaXMg c2hvdWxkIGJlIGV4cGFuZGVkIHdpdGggbW9yZQ0KaW5mb3JtYXRpb24gZXhwbGFpbmluZyB3aHkg d2UgZG8gbm90IHJlY29tbWVuZCByYW5kb20gY3VydmVzLg0KDQoxKSBUaGF0IHJhbmRvbSBjdXJ2 ZXMgYXJlIGhhcmQgdG8gcHJvdGVjdCBhZ2FpbnN0IHNpZGUtY2hhbm5lbCBhdHRhY2tzLg0KMikg Tm9uLXJhbmRvbSBjdXJ2ZXMgYXJlIHNpZ25pZmljYW50bHkgZmFzdGVyLCBzbyB0aGF0IGZvciBh IGZpeGVkIG51bWJlcg0Kb2Ygb3BlcmF0aW9ucywgcCBjYW4gYmUgbXVjaCBsYXJnZXIgZm9yIG5v bi1yYW5kb20gY3VydmVzLg0KDQo= From nobody Wed Nov 23 02:22:47 2016 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 3A2E7129868 for ; Wed, 23 Nov 2016 02:22:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.221 X-Spam-Level: X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 3jQkT611L9BH for ; Wed, 23 Nov 2016 02:22:44 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 656E812965A for ; Wed, 23 Nov 2016 02:22:43 -0800 (PST) X-AuditID: c1b4fb3a-97bff70000007918-d8-58356defc75a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by (Symantec Mail Security) with SMTP id 61.3C.31000.FED65385; Wed, 23 Nov 2016 11:22:42 +0100 (CET) Received: from ESESSMB307.ericsson.se ([169.254.7.62]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.03.0319.002; Wed, 23 Nov 2016 11:22:39 +0100 From: John Mattsson To: Yaron Sheffer , "Salz, Rich" , Sean Turner , "" Thread-Topic: [TLS] WGLC for draft-ietf-tls-rfc4492bis Thread-Index: AQHSQh6ZBtLjySIXQkGGsA9kkiXhRqDhNgaAgACkbYCAABeGgIAA2SuAgAOXuQA= Date: Wed, 23 Nov 2016 10:22:38 +0000 Message-ID: References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <7462904085cc4a94914298af81157031@usma1ex-dag1mb1.msg.corp.akamai.com> <7de8f9da-8ab1-cfc2-00ad-9c91c7694174@gmail.com> <8394bafcd99344838d878b5e8cf5b524@usma1ex-dag1mb1.msg.corp.akamai.com> <8262a7bf-6c19-0a23-9d0b-8f59344444aa@gmail.com> In-Reply-To: <8262a7bf-6c19-0a23-9d0b-8f59344444aa@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.9.160926 x-originating-ip: [153.88.183.20] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOIsWRmVeSWpSXmKPExsUyM2K7iu6nXNMIgzPzFSz+b+lksbiyqpHZ 4tP5LkaLVfdnsDuweEw+soDZY+esu+weS5b8ZPI4eJAxgCWKyyYlNSezLLVI3y6BK+Prn3Vs BUf4Kna0LWdpYJzC18XIySEhYCLxv+8PcxcjF4eQwDpGid6OK2wQzmJGiUmzl7GBVLEJGEjM 3dMAlhAR6GaUWLqplwUkISxgKvHpVR8riC0iYCaxaetcdgjbT6K36SyYzSKgKnHy2QuwQbwC 5hJX5/9kh9iwhUni0bcJYIM4BWwlZqz7zARiMwqISXw/tQbMZhYQl7j1ZD4TxK0CEkv2nGeG sEUlXj7+B7SYg0NUQE9izf0wiLCixNXpy5lAwswCmhLrd+lDTLGWmNh8kQXCVpSY0v2QHeIc QYmTM5+wTGAUm4Vk2SyE7llIumch6Z6FpHsBI+sqRtHi1OLi3HQjI73Uoszk4uL8PL281JJN jMDoO7jlt9UOxoPPHQ8xCnAwKvHwFsSaRAixJpYVV+YeYpTgYFYS4VUGxq4Qb0piZVVqUX58 UWlOavEhRmkOFiVxXrOV98OFBNITS1KzU1MLUotgskwcnFINjApH139mqhDuv64+STE/rDB8 +4FUy//qW1si1obsmvzxz9WPq5RZf9b89Cu8sN3w7DnNL1pXv9WtfPFqTqHAgpNP3erVDc5V 1PAsUlgdHNoU6rNZeV7ummbxO4GeYkqf3jVYbyvhNJKYG1s/03PCmg/cwRESH3bFJcd+/rzI bTmrquaF9wf1wpVYijMSDbWYi4oTAXPLYc+6AgAA Archived-At: Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 10:22:46 -0000 T24gMjAxNi0xMS0yMSwgMDY6MzEsICJUTFMgb24gYmVoYWxmIG9mIFlhcm9uIFNoZWZmZXIiDQo8 dGxzLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHlhcm9uZi5pZXRmQGdtYWlsLmNvbT4g d3JvdGU6DQoNCj5TbyB0aGUga2V5IHNjaGVkdWxlIGNoYW5nZWQgYW5kIHRoZXJlZm9yZSB3ZSB0 aGluayBjcm9zcy12ZXJzaW9uIGF0dGFja3MNCj5hcmUgaW1wb3NzaWJsZS4gSGF2ZSB3ZSBhbHNv IGFuYWx5emVkIG90aGVyIHByb3RvY29scyB0byBlbnN1cmUgdGhhdA0KPmNyb3NzIHByb3RvY29s IGF0dGFja3MsIGUuZy4gd2l0aCBTU0ggb3IgSVBzZWMsIGFyZSBvdXQgb2YgdGhlIHF1ZXN0aW9u Pw0KPg0KPlB1dCBkaWZmZXJlbnRseSwgYWxnb3JpdGhtIGRlc2lnbmVycyBnYXZlIHVzIGEgY2hl YXAsIGVhc3kgdG8gdXNlIHRvb2wNCj50byBhdm9pZCBhIGNsYXNzIG9mIHBvdGVudGlhbCBhdHRh Y2tzLiBXaHkgYXJlIHdlIGluc2lzdGluZyBvbiBub3QgdXNpbmcNCj5pdD8NCg0KVW5sZXNzIHNv bWVvbmUgcG9pbnRzIG91dCBhbnkgbWFqb3IgZGlzYWR2YW50YWdlcyB3aXRoIHVzaW5nIGEgY29u dGV4dCwgSQ0KYWdyZWUgd2l0aCBZYXJvbi4NCg0KDQo+DQo+VGhhbmtzLA0KPglZYXJvbg0KPg0K Pk9uIDIwLzExLzE2IDE3OjMzLCBTYWx6LCBSaWNoIHdyb3RlOg0KPj4+IEZvciB0aG9zZSB3aG8g bWlzc2VkIENVUkRMRSwgY291bGQgeW91IHBsZWFzZSBicmllZmx5IGV4cGxhaW4gd2h5IHdlDQo+ Pj5kb24ndA0KPj4+IG5lZWQgc2lnbmF0dXJlIGNvbnRleHQgaW4gbm9uLVRMUyBhcmVhcy4NCj4+ DQo+PiBUaGUgb25lIHBsYWNlIHdlIHdlcmUgY29uY2VybmVkIGFib3V0IGF0dGFja3Mgd2FzIGlu IHByZS1oYXNoDQo+PnNpZ25hdHVyZXMsIGFuZCB3ZSBtYWRlIHRob3NlIGEgTVVTVCBOT1QuICBB bmQgeWVzLCB5b3VyJ2UgcmlnaHQsIGl0J3MNCj4+bm90IHJlbGV2YW50IHRvIFRMUy4NCj4+DQo+ Pj4gU28gd2h5IGFyZSB3ZSBub3cgc2F5aW5nIHRoYXQgY29udGV4dHMgYXJlIG5vdCBuZWVkZWQg ZXZlbiBmb3IgVExTPw0KPj4NCj4+IEkgdGhpbmsgYmVjYXVzZSB0aGUga2V5IHNjaGVkdWxlIGNo YW5nZWQuDQo+Pg0KPj4gLS0NCj4+IFNlbmlvciBBcmNoaXRlY3QsIEFrYW1haSBUZWNobm9sb2dp ZXMNCj4+IE1lbWJlciwgT3BlblNTTCBEZXYgVGVhbQ0KPj4gSU06IHJpY2hzYWx6QGphYmJlci5h dCBUd2l0dGVyOiBSaWNoU2Fseg0KPj4NCj4+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5UTFMgbWFpbGluZyBsaXN0DQo+VExTQGlldGYub3Jn DQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg0K From nobody Wed Nov 23 03:39:45 2016 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 0E47F129CE5 for ; Wed, 23 Nov 2016 03:39:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de 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 gKzygCsE7iNA for ; Wed, 23 Nov 2016 03:39:40 -0800 (PST) Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3761912996D for ; Wed, 23 Nov 2016 03:39:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id DC69D12E932B for ; Wed, 23 Nov 2016 12:39:37 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1479901176; x= 1480765177; bh=WtwUf2J5GnB8FO2lTICM8VV6f1X5Phtfynjdd0OopgQ=; b=C GlX8QjpNgZZ+jEbrjxjBTwnGKLiVcTeJKXNvPzGNKpylr+L2OK8jafCxtsJo6hns gNJiRkhDX2Dg/sJDr2ucWAY3A2XX/FfcKJRcBzi/fl//A0KBCamPrr/Q9cNF6uoJ ECIP0iJlYZQ88rB5ON5WUylMnNC1izRbRDaUrWo60Y= X-Virus-Scanned: amavisd-new at hs-offenburg.de Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hu8tbMvxHDzx for ; Wed, 23 Nov 2016 12:39:36 +0100 (CET) Received: from gwia2.rz.hs-offenburg.de (gwia2.rz.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id AC2E212E9326 for ; Wed, 23 Nov 2016 12:39:36 +0100 (CET) Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Wed, 23 Nov 2016 12:39:36 +0100 Message-Id: <58358E07020000AC00121380@gwia2.rz.hs-offenburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.1 Date: Wed, 23 Nov 2016 12:39:35 +0100 From: "Andreas Walz" To: References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> <79f10997-3bbc-fbce-91ae-2ceecaaa653e@akamai.com> In-Reply-To: <79f10997-3bbc-fbce-91ae-2ceecaaa653e@akamai.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part9DA4FDE7.0__=" Archived-At: Subject: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 11:39:43 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part9DA4FDE7.0__= Content-Type: multipart/alternative; boundary="=__Part9DA4FDE7.1__=" --=__Part9DA4FDE7.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Dear all, bringing up this thread again .... In the course of studying the way TLS implementations treat the "version" (or=20 "legacy_record_version") field in the record header, we were wondering=20 (please excuse if we missed some arguments here from past discussions): (1) What is an implementation (in particular when receiving the first bytes over a new connection) supposed to do if the record's version field=20 signals a protocol version the implementation does not support? I=20 understand that, at this stage, enforcing a specific value (e.g. 0x0301=20 according to the TLSv1.3 draft) is detrimental to interoperability.=20 However, if that field bears any meaning (in either TLSv1.3 or previous=20 versions), what is it? I would expect this field is supposed to allow=20 signaling a potentially non-backward compatible record format=20 (inauspiciously interfering with a receiver disregarding the record=20 version). Provided this field isn't treated as an enum, what about=20 checking/enforcing at least the major version as BoringSSL does (as far=20 as I know)? In any case, I would propose to be very clear about this in=20 the text (my sense was that there is some work in progress, but I=20 couldn't find anything). In implementations (>> Benjamin Kaduk 11/10/16 5:22 PM >>> On 11/08/2016 06:25 PM, Martin Thomson wrote: On 9 November 2016 at 05:59, Brian Smith = wrote: This isn't a pervasively shared goal, though. It's good to = let the browsers police things if they want, but I think a lot of implementations would prefer to avoid doing work that isn't necessary for interop or security. If you permit someone to enforce it, then that is sufficient.= I don't think that we should ever force someone to enforce these sorts of things (as you say, sometimes strict enforcement isn't cheap or even desirable). =20 Agreed. We should probably change the text a bit, though, as right = now readers can get two different readings depending on whether they = go for a strict decode_error (or illegal_parameter?) since the struct = doesn't match the definition, or follow the "MUST be ignored for all = purposes". =20 -Ben =20 --=__Part9DA4FDE7.1__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML =0Abody p =0A{ =0A margin: 0px; =0A}=0A
Dear all,

bringing up this = thread again ....

In the course=0A of studying the way TLS = implementations treat the "version" (or =0A"legacy_record_version") field = in the record header, we were wondering =0A(please excuse if we missed = some arguments here from past discussions):

(1)=0A What is an = implementation (in particular when receiving the first bytes=0A over a new = connection) supposed to do if the record's version field =0Asignals a = protocol version the implementation does not support? I =0Aunderstand = that, at this stage, enforcing a specific value (e.g. 0x0301 =0Aaccording = to the TLSv1.3 draft) is detrimental to interoperability. =0AHowever, if = that field bears any meaning (in either TLSv1.3 or previous =0Aversions), = what is it? I would expect this field is supposed to allow =0Asignaling a = potentially non-backward compatible record format =0A(inauspiciously = interfering with a receiver disregarding the record =0Aversion). Provided = this field isn't treated as an enum, what about =0Achecking/enforcing at = least the major version as BoringSSL does (as far =0Aas I know)? In any = case, I would propose to be very clear about this in =0Athe text (my sense = was that there is some work in progress, but I =0Acouldn't find anything). = In implementations (<TLSv1.3), we found all =0Akinds of interpretations.=

(2) What is an implementation (up to =0ATLSv1.2, as the TLSv1.3 = spec is rather clear about that) supposed to use=0A for the record's = protocol version field before a version has been =0Aagreed upon (e.g. when = sending an alert after receiving an unparsable =0AClientHello)? My best = guess would be to set it to the lowest (TLS) =0Aprotocol version that uses = the same record format (probably 0x0301). =0AHowever, we observe several = servers which, in such cases, answer with an=0A alert with weird record = protocol version values, e.g. 0x0000.]

Thanks and Cheers,
Andi
___________________________________

Andreas Walz
Research = Engineer
Institute of reliable Embedded Systems and Communication = Electronics (ivESK)
Offenburg University of Applied Sciences, 77652 = Offenburg, Germany

 

>>> Benjamin Kaduk <bkaduk@akama= i.com> 11/10/16 5:22 PM >>>
 On 11/08/2016 06:25 = PM, Martin Thomson wrote:
On 9 November =
2016 at 05:59, Brian Smith <brian@briansmith.org> wrote:
= 
This isn't a pervasively shared goal, =
though. It's good to let the browsers
police things if they want, but I =
think a lot of implementations would
prefer to avoid doing work that =
isn't necessary for interop or security.
= 
If you permit someone to enforce it, then that is sufficient.  I =
don't
think that we should ever force someone to enforce these sorts =
of
things (as you say, sometimes strict enforcement isn't cheap or =
even
desirable).

Agreed.  = We should probably change the text a bit, though, as right now readers = can get two different readings depending on whether they go for a = strict decode_error (or illegal_parameter?) since the struct doesn't = match the definition, or follow the "MUST be ignored for all purposes".=

-Ben
--=__Part9DA4FDE7.1__=-- --=__Part9DA4FDE7.0__=-- From nobody Wed Nov 23 05:10:12 2016 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 2835A129D81 for ; Wed, 23 Nov 2016 05:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 BQSbeD2yT2VP for ; Wed, 23 Nov 2016 05:10:09 -0800 (PST) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (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 C2D7212960D for ; Wed, 23 Nov 2016 05:10:09 -0800 (PST) Received: by mail-yw0-x22e.google.com with SMTP id a10so10601131ywa.3 for ; Wed, 23 Nov 2016 05:10:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OUXbIB0jTbgIKEfTCIe6D3BdYMM5qX/3Hkh+ojI9cbk=; b=x/3torAdNfICSWLmX0bZnlSsxe4fZbvOlsPn6Rh3dUDskNLvCSnigylvGnHcwPGdTo ADyyX4MUYj9Okce6OaYR2fpOJqpByk/Yv79FYbdRTHecRBhHhRaHn8kq5SHZfbNxRbfd oFtt0YM8Fgo3qmQZbCMPl1O1hdRPKmiJBTnEdydvi6UeBr0ASuPdGjftQPEuMSkjpfRs MoWXii80cwBRrJ9wKoYIKGG8nlWlQM872FH5N1XXnW8h/4oGRBf9bKLJiCBOKzyZGosY tp/+RqOotter6D2IBXJpgdTfQ6CU39km0piQiHL6TrZLs1N7vVJHz5r5U0tn/7n68wwT OMdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OUXbIB0jTbgIKEfTCIe6D3BdYMM5qX/3Hkh+ojI9cbk=; b=UGfe9qaFSFlo4oO4jzl6o7gEI/C8J94uvGgdIBsVm4xE+rYVIH9i/7/2sQFOtewTG6 pgDGDSrEM6lmUYlbWukFUp+2CxaOnDXPKKZX7DAjpdAgQwiOTaFLNcyoV/isX5wpfr7Z zZUCx4iJGa64JeD1YxoT0JpXmwLhiQJ44XHoFRT+6rfmD0aLjINm3e8rMHwPCGEypMxv V/k/2W8W2D5vOmNrChE9vjwPhq7BSfLWjLvtJQfixpGYd/GBdOMIJQd6AaCw46pmcxos IHrPrjp8wv5LmVYR5mfMfQYnUBMohtkO7th3t81qsB3PMB+DpRfCb+6J9ddpAMF5ZoI1 oaHQ== X-Gm-Message-State: AKaTC007qBsXvemhhFek9H/8xhxnHcS79yfQeShLcaG44/VZNCZ/W1FBPnSVY2k1XpCoy/p0wxmoA/hYI77Cng== X-Received: by 10.129.53.194 with SMTP id c185mr3092786ywa.205.1479906609089; Wed, 23 Nov 2016 05:10:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Wed, 23 Nov 2016 05:09:28 -0800 (PST) In-Reply-To: <58355120.5030800@ssi.gouv.fr> References: <20161122190344.GC19978@neoplankton.picty.org> <58355120.5030800@ssi.gouv.fr> From: Eric Rescorla Date: Wed, 23 Nov 2016 05:09:28 -0800 Message-ID: To: Olivier Levillain Content-Type: multipart/alternative; boundary=001a11421478bc96000541f79b2c Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 13:10:11 -0000 --001a11421478bc96000541f79b2c Content-Type: text/plain; charset=UTF-8 On Wed, Nov 23, 2016 at 12:19 AM, Olivier Levillain < olivier.levillain@ssi.gouv.fr> wrote: > Hi, > > >> Being able to send supported_groups does allow a server to choose to > make > >> a tradeoff between an extra round trip on the current connection and its > >> own group preferences. One example where a server might want to do this > is > >> where it believes that X25519 is likely a more future-proof group and > would > >> prefer that, but still believes the client's choice of P256 is suitable > for > >> this connection. Always requiring an extra round trip might end up being > >> expensive depending on the situation so some servers might prefer to > avoid > >> sending an HRR for a slightly more preferred group. > >> > >> I think that requiring the client to maintain state from the > >> supported_groups puts undue requirements on the client, since not all > >> clients keep state between connections, and those that do usually only > keep > >> session state for resumption. > >> > > This matches my view as well. > > > > I agree that the client should not be require to keep state. I do not > > believe that the draft requires this, but if someone thinks otherwise, > > please send a PR to fix. > > > > There were actually two points in my message: > - I was not convinced by this way of signalling a preference without > enforcing it, but I understand that, if we keep supported_groups, it > does not cost much and the client can safely ignore the server sent > extension; > - however, I found strange that the specification stated that the > client could update its view when seeing this extension, but that it was > not stated in the case of an HRR where updating its views of the > servers' preference would clearly be useful for the future. I only > proposed to add the same text "The client MAY update its view of the > server's preference when receiving an HRR, to avoid the extra round trip > in future encounters". > This is is unsafe, because the HRR is unauthenticated. We could update it after the handshake completes, but I think this is obvious enough that it doesn't need to be stated. -Ekr --001a11421478bc96000541f79b2c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 23, 2016 at 12:19 AM, Olivier Levillain &= lt;olivi= er.levillain@ssi.gouv.fr> wrote:
Hi,

>> Being able to send supported_groups does allow a server to choose = to make
>> a tradeoff between an extra round trip on the current connection a= nd its
>> own group preferences. One example where a server might want to do= this is
>> where it believes that X25519 is likely a more future-proof group = and would
>> prefer that, but still believes the client's choice of P256 is= suitable for
>> this connection. Always requiring an extra round trip might end up= being
>> expensive depending on the situation so some servers might prefer = to avoid
>> sending an HRR for a slightly more preferred group.
>>
>> I think that requiring the client to maintain state from the
>> supported_groups puts undue requirements on the client, since not = all
>> clients keep state between connections, and those that do usually = only keep
>> session state for resumption.
>>
> This matches my view as well.
>
> I agree that the client should not be require to keep state. I do not<= br> > believe that the draft requires this, but if someone thinks otherwise,=
> please send a PR to fix.
>

There were actually two points in my message:
=C2=A0- I was not convinced by this way of signalling a preference without<= br> enforcing it, but I understand that, if we keep supported_groups, it
does not cost much and the client can safely ignore the server sent
extension;
=C2=A0- however, I found strange that the specification stated that the
client could update its view when seeing this extension, but that it was not stated in the case of an HRR where updating its views of the
servers' preference would clearly be useful for the future. I only
proposed to add the same text "The client MAY update its view of the server's preference when receiving an HRR, to avoid the extra round tri= p
in future encounters".

This is is = unsafe, because the HRR is unauthenticated. We could update it
af= ter the handshake completes, but I think this is obvious enough that it doe= sn't
need to be stated.

-Ekr
--001a11421478bc96000541f79b2c-- From nobody Wed Nov 23 05:18:48 2016 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 4C9E3129DB3 for ; Wed, 23 Nov 2016 05:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 EZXgzcaXvYr5 for ; Wed, 23 Nov 2016 05:18:34 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 ADE3D129BD8 for ; Wed, 23 Nov 2016 05:18:34 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id a10so10798660ywa.3 for ; Wed, 23 Nov 2016 05:18:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=5+FigfvlwK9jPzvJddRIYJwBU2I2lJX+YdJso1e/raw=; b=gWwyTyQVNjjL/3nCGpztawI01Vl1lAgrijNc2h3WXDMupqRl5ro/RLNuMV+KrzhH1A W0EIqqk8pP0a7ORB5deJ4TtNFyopmYsfc98GxFwvzFIyOZ1KhXMzXXKkL2+2prAAZOR8 Y/E/VblLpHEVZwRx7Coq7YGqRYrKCh+1KdAyzmIz2syaTZJltXWiA8Sg3ycS/EOaVtXc QF/pP+9entdBavzbot8lc82t3BTq2HdnjkNk7x7EMVBLA+p3owIPkO8L0PueEtH+CqeH zSWnrMkKBeZMeuHpBk57eX3So3iNxE5TPC9FjvASniZgbIiU32uZRRa2GqXnybgpFGuT argw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=5+FigfvlwK9jPzvJddRIYJwBU2I2lJX+YdJso1e/raw=; b=PV3IyTvSj12i+C77pncVO5dKK+wI5k059jrOGocqRWb1zodK0Yemd2LKcbEyW+tqjK SLcEj6WxCQfucABqruyOXVV/Uelilu3UdjGAkYd1WyVKc+Ygkh19MblGOvgazCp9TTx1 xJfNWcZAbA9fuVQ0z1fF02RUgZigiJanOyhF+m0/hhCMaCV1d3n41o6zM2wHolTrL57E 3UonLXf+ZVjhAu2eIUqDW5dz3qYIDJ44lZJDxmAp1eD7jyEr+vUGp2by8YEHyINWmO96 QLdO6qwj8CZlCKopUqGmIbmV6LB2cNwCE9j6is4jVjzoMiiy4Yjy2ewma3ICJcSGYAmd YmSg== X-Gm-Message-State: AKaTC00rUlo3R5aQbw7r4KrLySBZArZCZsbiCBbTolEdr7w5sQ5weQc39WyYPEe6LfYd6CZkpRP/NwEfn+cAXQ== X-Received: by 10.13.195.5 with SMTP id f5mr3655665ywd.354.1479907113922; Wed, 23 Nov 2016 05:18:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Wed, 23 Nov 2016 05:17:52 -0800 (PST) In-Reply-To: <58358E07020000AC00121380@gwia2.rz.hs-offenburg.de> References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> <79f10997-3bbc-fbce-91ae-2ceecaaa653e@akamai.com> <58358E07020000AC00121380@gwia2.rz.hs-offenburg.de> From: Eric Rescorla Date: Wed, 23 Nov 2016 05:17:52 -0800 Message-ID: To: Andreas Walz Content-Type: multipart/alternative; boundary=001a114d5fd6d3b5d60541f7b9a0 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 13:18:46 -0000 --001a114d5fd6d3b5d60541f7b9a0 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 23, 2016 at 3:39 AM, Andreas Walz wrote: > Dear all, > > bringing up this thread again .... > > In the course of studying the way TLS implementations treat the "version" > (or "legacy_record_version") field in the record header, we were wondering > (please excuse if we missed some arguments here from past discussions): > > (1) What is an implementation (in particular when receiving the first > bytes over a new connection) supposed to do if the record's version field > signals a protocol version the implementation does not support? I > understand that, at this stage, enforcing a specific value (e.g. 0x0301 > according to the TLSv1.3 draft) is detrimental to interoperability. > However, if that field bears any meaning (in either TLSv1.3 or previous > versions), what is it? I would expect this field is supposed to allow > signaling a potentially non-backward compatible record format > (inauspiciously interfering with a receiver disregarding the record > version). Provided this field isn't treated as an enum, what about > checking/enforcing at least the major version as BoringSSL does (as far as > I know)? In any case, I would propose to be very clear about this in the > text (my sense was that there is some work in progress, but I couldn't find > anything). In implementations ( interpretations. > In general, it should ignore it. It's going to become increasingly common to have this be a version you don't support given the recommendation to use 0301 and the ongoing deprecation of TLS 1.0. I think it would be fine to sanity check the major version, but I'm not sure what would be gained by requiring this. > (2) What is an implementation (up to TLSv1.2, as the TLSv1.3 spec is > rather clear about that) supposed to use for the record's protocol version > field before a version has been agreed upon (e.g. when sending an alert > after receiving an unparsable ClientHello)? My best guess would be to set > it to the lowest (TLS) protocol version that uses the same record format > (probably 0x0301). However, we observe several servers which, in such > cases, answer with an alert with weird record protocol version values, e.g. > 0x0000.] > Yes, this seems like a reasonable procedure. Not sure how to tell TLS 1.2 impls what to do at this point, though. -Ekr > > Thanks and Cheers, > Andi > > ___________________________________ > > Andreas Walz > Research Engineer > Institute of reliable Embedded Systems and Communication Electronics > (ivESK) > Offenburg University of Applied Sciences, 77652 Offenburg, Germany > > > > >>> Benjamin Kaduk 11/10/16 5:22 PM >>> > On 11/08/2016 06:25 PM, Martin Thomson wrote: > > On 9 November 2016 at 05:59, Brian Smith wrote: > > This isn't a pervasively shared goal, though. It's good to let the browsers > police things if they want, but I think a lot of implementations would > prefer to avoid doing work that isn't necessary for interop or security. > > If you permit someone to enforce it, then that is sufficient. I don't > think that we should ever force someone to enforce these sorts of > things (as you say, sometimes strict enforcement isn't cheap or even > desirable). > > > Agreed. We should probably change the text a bit, though, as right now > readers can get two different readings depending on whether they go for a > strict decode_error (or illegal_parameter?) since the struct doesn't match > the definition, or follow the "MUST be ignored for all purposes". > > -Ben > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a114d5fd6d3b5d60541f7b9a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 23, 2016 at 3:39 AM, Andreas Walz <andreas.walz= @hs-offenburg.de> wrote:
Dear all,

bringi= ng up this thread again ....

In the course of studying the way TLS implementations treat the "version" (or= =20 "legacy_record_version") field in the record header, we were wond= ering=20 (please excuse if we missed some arguments here from past discussions):
=
(1) What is an implementation (in particular when receiving the first bytes over a new connection) supposed to do if the record's version field=20 signals a protocol version the implementation does not support? I=20 understand that, at this stage, enforcing a specific value (e.g. 0x0301=20 according to the TLSv1.3 draft) is detrimental to interoperability.=20 However, if that field bears any meaning (in either TLSv1.3 or previous=20 versions), what is it? I would expect this field is supposed to allow=20 signaling a potentially non-backward compatible record format=20 (inauspiciously interfering with a receiver disregarding the record=20 version). Provided this field isn't treated as an enum, what about=20 checking/enforcing at least the major version as BoringSSL does (as far=20 as I know)? In any case, I would propose to be very clear about this in=20 the text (my sense was that there is some work in progress, but I=20 couldn't find anything). In implementations (<TLSv1.3), we found all= =20 kinds of interpretations.

=
In general, it should ignore it. It's going to become increasingly= common to have this be a version you don't support given the recommend= ation to use 0301 and the ongoing deprecation of TLS 1.0. I think it would = be fine to sanity check the major version, but I'm not sure what would = be gained by requiring this.=C2=A0

=C2=A0
(2) What is an implementation (up to=20 TLSv1.2, as the TLSv1.3 spec is rather clear about that) supposed to use for the record's protocol version field before a version has been=20 agreed upon (e.g. when sending an alert after receiving an unparsable=20 ClientHello)? My best guess would be to set it to the lowest (TLS)=20 protocol version that uses the same record format (probably 0x0301).=20 However, we observe several servers which, in such cases, answer with an alert with weird record protocol version values, e.g. 0x0000.]

Yes, this seems like a reasonabl= e procedure. Not sure how to tell TLS 1.2 impls what to do at this point, t= hough.

-Ekr
=C2=A0

Tha= nks and Cheers,
Andi

___________________________________
=
Andreas Walz
Research Engineer
Institute of reliable Embedded Sys= tems and Communication Electronics (ivESK)
Offenburg University of Appli= ed Sciences, 77652 Offenburg, Germany

=C2=A0

>>> B= enjamin=C2=A0Kaduk=C2=A0<bkaduk@akamai.com> 11/10/16 5:22 PM >>>
On 11/08/2016 06:25 PM, Martin Thomson wrote:
= 
On 9 November 2016 at 05:59, Brian Smith <brian@briansmith.org> wrote:
This isn't a pervasively shared goal, though. It&#=
39;s good to let the browsers
police things if they want, but I think a =
lot of implementations would
prefer to avoid doing work that isn't n=
ecessary for interop or security.
=
If you permit someone to enforce it, then that is sufficient.  I don't<=
br>think that we should ever force someone to enforce these sorts of
thi=
ngs (as you say, sometimes strict enforcement isn't cheap or even
de=
sirable).

Agreed.=C2=A0 We should = probably change the text a bit, though, as right now readers can get tw= o different readings depending on whether they go for a strict decode_e= rror (or illegal_parameter?) since the struct doesn't match the def= inition, or follow the "MUST be ignored for all purposes".
-Ben

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--001a114d5fd6d3b5d60541f7b9a0-- From nobody Wed Nov 23 05:25:25 2016 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 7BCAC129DB7 for ; Wed, 23 Nov 2016 05:25:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 thxFkmg6CeKv for ; Wed, 23 Nov 2016 05:25:22 -0800 (PST) Received: from smtp.ssi.gouv.fr (smtp.ssi.gouv.fr [86.65.182.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4EAD129DB4 for ; Wed, 23 Nov 2016 05:25:22 -0800 (PST) Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id 1776190B930; Wed, 23 Nov 2016 14:25:21 +0100 (CET) To: Eric Rescorla References: <20161122190344.GC19978@neoplankton.picty.org> <58355120.5030800@ssi.gouv.fr> From: Olivier Levillain Message-ID: <583598C1.5090601@ssi.gouv.fr> Date: Wed, 23 Nov 2016 14:25:21 +0100 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 13:25:24 -0000 >> There were actually two points in my message: >> - I was not convinced by this way of signalling a preference without >> enforcing it, but I understand that, if we keep supported_groups, it >> does not cost much and the client can safely ignore the server sent >> extension; >> - however, I found strange that the specification stated that the >> client could update its view when seeing this extension, but that it was >> not stated in the case of an HRR where updating its views of the >> servers' preference would clearly be useful for the future. I only >> proposed to add the same text "The client MAY update its view of the >> server's preference when receiving an HRR, to avoid the extra round trip >> in future encounters". >> > This is is unsafe, because the HRR is unauthenticated. We could update it > after the handshake completes, but I think this is obvious enough that it > doesn't > need to be stated. Unless I am mistaken, EncryptedExtensions is not authenticated either (even if it is sent in the same flight as the authentication messages), so updating the client cache can not be done immediately after interpreting the supported_groups extension. However, if you believe this does not need to be stated, I am fine with that. olivier From nobody Wed Nov 23 05:33:00 2016 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 B0B92129C86 for ; Wed, 23 Nov 2016 05:32:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1CLcxhJas2YY for ; Wed, 23 Nov 2016 05:32:57 -0800 (PST) Received: from mail-wj0-x230.google.com (mail-wj0-x230.google.com [IPv6:2a00:1450:400c:c01::230]) (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 D03E112958E for ; Wed, 23 Nov 2016 05:32:56 -0800 (PST) Received: by mail-wj0-x230.google.com with SMTP id qp4so9534467wjc.3 for ; Wed, 23 Nov 2016 05:32:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0sacCIgO3HOc1jgRI1yRa1eTEaoDfYn0gvqrOWXseWI=; b=jEfl0ABHO5xsKIGcXzsR7lKEfwbf78m05+fHM0tNI/TVJydQJQmJXleyA6vmPWb83U jAfZhjc8VQQag9CKCh+wTQ8TvN9RzoMkyYVykhJxaTw+EFDDtsQmjf43t3lzLmRH3FKy LnbFUh5T9o2gZd89kh0AgXlEhKme85qPmieKcdwttlUFfIrDqER5Ee9Z9ZbIyBOMWJNr gF0n9Ng0Se62qlW0GsRp6haOWaUBfE5XStACSLPyiZHsZlMO6s8qxZxFrYyCApU52VBT 9quyGtzM7Kv95WqVUnjaat27tHX9gnqNhQQyB8ZOJBNezlNV7rx49a/hLotRN/TRLS6O /weQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=0sacCIgO3HOc1jgRI1yRa1eTEaoDfYn0gvqrOWXseWI=; b=kqst5khBxvnZxP2vhDSxM2HIlQvIXIwRl+8QDYcELn/JHL85QXXRPl0iPMUBP4FjEl gICqA1AmevF//7Jqqh7rn/mUl53Cg3TGdLkeQc3vM74PO5QFdIzVdpqNqApGc3xqW/C/ EtTOJ6IxvLG/D3ehJvTXGXAE4nz4s+bmaBmtL2vlFloCVh4l5oRsfmrByyd3sAMYNa0c pzQbQ/5UkwFQIdhn/to/aVv7T1iQqAQgAz+WweCxpz+grhTVn9da2BF+krbNJbpjKoEi a278NkYojfYB5BUUnhbOfcUyAfaP0SI3W4g4Rp+SKhLHHEKWbC6zYDEUf8oq1rkyb28F PKNA== X-Gm-Message-State: AKaTC03goYX75wuv6T55QFm85OEpvSCg490zVF0l9ocAeBINBRzmiFqRa/j/p1oyt9f33Q== X-Received: by 10.194.235.198 with SMTP id uo6mr3846206wjc.40.1479907975135; Wed, 23 Nov 2016 05:32:55 -0800 (PST) Received: from macbook-pro-2.mshome.net ([176.13.8.210]) by smtp.gmail.com with ESMTPSA id i15sm36397793wjs.16.2016.11.23.05.32.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 05:32:54 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: Date: Wed, 23 Nov 2016 15:32:52 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <48C23517-6EFD-4A3C-A020-9CC1A87469B8@gmail.com> References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> To: John Mattsson X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "" Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 13:32:59 -0000 Hi, John Thanks for the review. See my responses below: > On 23 Nov 2016, at 12:15, John Mattsson = wrote: >=20 > I have not read the processing parts in detail. Here are comments on = the > first and last sections of the document. >=20 > Cheers, > John >=20 > - Somewhere > I suggest adding the following sentence from TLS 1.3: > "Applications SHOULD also enforce minimum and maximum key sizes. For > example, certification paths containing keys or signatures weaker than > 2048-bit RSA or 224-bit ECC are not appropriate for secure = applications." >=20 > This is as true for TLS 1.0, 1.1, and 1.2 as for TLS 1.3 I can add a sentence like that, but the draft does even better: It = deprecates all curves smaller than 256-bit ECC. Now it=E2=80=99s true = that this draft is about TLS, not PKIX, so this only forces the public = key in the EE certificate to be at least 256-bit, but in general CA keys = are no weaker than EE keys. I will add such a sentence , though. > - Section 1 > "Compared to currently prevalent cryptosystems such as RSA, ECC = offers" >=20 > I think this should be updated, ECDHE is already very well-spread. Yes, this is copied from 4492. How about: =E2=80=9CCompared to previous = cryptosystems such as RSA and finite-field diffie-hellman, ECC = offers=E2=80=A6" > - Section 1 > "This is illustrated in the following table, based on = [Lenstra_Verheul], > which gives approximate comparable key sizes for symmetric- and > asymmetric-key cryptosystems based on the best-known algorithms for > attacking them." >=20 > The key sizes for DH/DSA/RSA does not seem to be based on the > Lenstra-Verheuls equations which gives much higher key sizes for > DH/DSA/RSA. >=20 > The DH/DSA/RSA key sizes seem to be based on NIST recommendations. I > suggest either: >=20 > A) Fully based the table on NIST recommendation, which means keeping > DH/DSA/RSA as is but simplifying ECC to 2 * Symmetric. > B) Update the DH/DSA/RSA key sizes based on state-of-the-art. But then = I > would say that this is not [Lenstra_Verheul], but rather [RFC3766], > [Lenstra 2004], [ECRYPT 2012]. I think these three all use the same > equation. > C) Just remove DH/DSA/RSA as the draft is about ECC. I=E2=80=99m inclined to get rid of this table and all the text from = =E2=80=9CThis is illustrated=E2=80=A6=E2=80=9D entirely. ECC is by now = in wide use. We don=E2=80=99t need to =E2=80=9Csell=E2=80=9D it any = more. so unless someone would like to make a PR with better text, I will = just get rid of it. >=20 > - Section 2 > "However, the computational cost incurred by a server is higher for > ECDHE_RSA than for the traditional RSA key exchange, which does not > provide forward secrecy." >=20 > True, but I think it gives the wrong impression. I think the = additional > cost is negligible. I don't have any TLS benchmarks but for i5-6600, > bench.cr.yp.to gives: >=20 > ronald3072 decrypt 8776864 cycles >=20 > ronald3072 sign 8781842 cycles > curve25519 keygen 163200 cycles > curve25519 compute 165816 cycles >=20 > That's only 3.8% overhead for crypto, and much less if calculated for = the > whole handshake. I suggest removing the sentence, or writing that the > additional server cost for forward secrecy is negligible and well = worth it. Makes sense. How about: OLD: However, the computational cost incurred by a server is higher NEW: The computational cost incurred by a server is marginally higher >=20 > - Section 6 > "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256" >=20 > Should this be "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"? > I don't think the document should recommend support of cipher suites > without forward secrecy. Definitely. It would be a very poor show to deprecate this ciphersuite = (along with all other ECDH_RSA and ECDH_ECDSA ciphersuites), declare = that all ciphersuites have forward secrecy, and then make this (sort of = ) MTI. Will fix. >=20 > - Section 7 > "documemts" -> =E2=80=9Cdocuments" OK >=20 > - Section 7 > "NEED TO ADD A PARAGRAPH HERE ABOUT WHY X25519/X448 ARE PREFERRABLE TO > NIST CURVES." >=20 > I suggest using the excellent explanation in RFC7748 as a basis. > Suggestion: >=20 > "Modern curves such X25519 and X448 [RFC7748] are preferable as they = lend > themselves to constant-time implementation and an exception-free = scalar > multiplication that is resistant to a wide range of side-channel = attacks, > including timing and cache attacks. For more information see = [SafeCurves]." >=20 > [SafeCurves] https://safecurves.cr.yp.to/ Cool. Will add. > - Section 7 > "Substantial additional information on elliptic curve choice can be = found > in [IEEE.P1363.1998], [ANSI.X9-62.2005], and [FIPS.186-4]". >=20 > I think it is better to refer people to [SafeCurves]. In addition, OK. I don=E2=80=99t think we should remove everything else, = especially when unlike 7748 this draft is specifying NIST curves, and = the choice for them was not in [SafeCurves] > - Section 7 > The paragraph about structure gives the impression that "F_p with p > random" is the optimal choice. I think this should be expanded with = more > information explaining why we do not recommend random curves. >=20 > 1) That random curves are hard to protect against side-channel = attacks. > 2) Non-random curves are significantly faster, so that for a fixed = number > of operations, p can be much larger for non-random curves. I think the explanation above covers this, but we may want to mention = that even the NIST curves are faster than random. Yoav= From nobody Wed Nov 23 05:36:03 2016 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 6B117129DCC for ; Wed, 23 Nov 2016 05:36:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 yEVj3IFZ62WN for ; Wed, 23 Nov 2016 05:36:01 -0800 (PST) Received: from mail-yw0-x233.google.com (mail-yw0-x233.google.com [IPv6:2607:f8b0:4002:c05::233]) (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 D8E42129DC9 for ; Wed, 23 Nov 2016 05:36:00 -0800 (PST) Received: by mail-yw0-x233.google.com with SMTP id r204so11356039ywb.0 for ; Wed, 23 Nov 2016 05:36:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wb/0FIoRNAUexm951jJzOMP9DijRQAyCcc3k+c9h6PU=; b=erdOqxBQaj5Y14pKIygxj4pD/aRRkE5x/4C5PPtmp7I482d08vSYo0gyGdKUZrcSpf Hdvr0bzDmdous2A5syIQGK/xosrmbwMG3g+U1wpBsOuxX+o5W8W/ibsyxPze5RxZ7VEG l3lPe3Nt7RVLkqyo/n/KSfjBwLejSRFfRkEQenHRWWkv03xIpsVtmoMHAXw/bDn0EPcf 3fy4vHFTcmcYYSOSQqLDZbCIk1bmMuLqh5/tXgzTPmVsc07UD3adp5IO0JWZRm/wMdPm dIRtW8H/aeVGUjGO9xD3LrWOOFcUrX2NVzwHIyc1Uv5K4m4KfMNrPKkiib+jXggG/4za MbdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wb/0FIoRNAUexm951jJzOMP9DijRQAyCcc3k+c9h6PU=; b=gbpYenLqPNDhNypDls0VJ2pArnSLJcKtv6rb0C5ohz8Op7qkAagdqWLqH6k3GMvktr WWnRseaPNgYtvqoWC3L6tji2QYaXE52yKY+dmSfiCxM6Z57jHVXhWmLdstovHHJmgUl7 ROfGxsWSqE2s2CUMB3FAkUXRqKB4ys7aaACvapG8ilIMVQq6oCUBXnGRek2U/Qir2/O3 XVHrUhr4htvf06oqQJ/GNifE6WUewwG7O0BipDGMU8w/8zmbwf79QkdUDmXRyXe8XoKb bjDeZwWOt81tG0yWVm7f7N80R2+CP1jrOJXXs8jpgFAEYTFobh39UUzStUlsP7PPXXtK 8AlA== X-Gm-Message-State: AKaTC00+HDxmKCJbhcUHQmPylQT6MYX0kPHtiieyO/wpRTf6TFFi57/+bNz6EwLXXyWIwoGK9n3oIvNT0zqGYA== X-Received: by 10.129.53.194 with SMTP id c185mr3235882ywa.205.1479908160131; Wed, 23 Nov 2016 05:36:00 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Wed, 23 Nov 2016 05:35:19 -0800 (PST) In-Reply-To: <583598C1.5090601@ssi.gouv.fr> References: <20161122190344.GC19978@neoplankton.picty.org> <58355120.5030800@ssi.gouv.fr> <583598C1.5090601@ssi.gouv.fr> From: Eric Rescorla Date: Wed, 23 Nov 2016 05:35:19 -0800 Message-ID: To: Olivier Levillain Content-Type: multipart/alternative; boundary=001a114214782f79f90541f7f866 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 13:36:02 -0000 --001a114214782f79f90541f7f866 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 23, 2016 at 5:25 AM, Olivier Levillain < olivier.levillain@ssi.gouv.fr> wrote: > >> There were actually two points in my message: > >> - I was not convinced by this way of signalling a preference without > >> enforcing it, but I understand that, if we keep supported_groups, it > >> does not cost much and the client can safely ignore the server sent > >> extension; > >> - however, I found strange that the specification stated that the > >> client could update its view when seeing this extension, but that it was > >> not stated in the case of an HRR where updating its views of the > >> servers' preference would clearly be useful for the future. I only > >> proposed to add the same text "The client MAY update its view of the > >> server's preference when receiving an HRR, to avoid the extra round trip > >> in future encounters". > >> > > This is is unsafe, because the HRR is unauthenticated. We could update it > > after the handshake completes, but I think this is obvious enough that it > > doesn't > > need to be stated. > > Unless I am mistaken, EncryptedExtensions is not authenticated either > (even if it is sent in the same flight as the authentication messages), > so updating the client cache can not be done immediately after > interpreting the supported_groups extension. > That is intended to be covered by the following text: by the client. Clients MUST NOT act upon any information found in "supported_groups" prior to successful completion of the handshake, but MAY use the information learned from a successfully completed handshake to change what groups they use in their "key_share" extension in subsequent connections. My point about HRR is that the client can generally update its opinion based on what it successfully completed the handshake with. This can happen either with HRR or when it offered >1 shares and the server took one. The special case is when supported_versions indicates a key type you didn't use. So I think if we wanted text around this it would go somewhere that covered the general case. I'm not sure it's needed but if the WG feels like we should add some text, I can... -Ekr > However, if you believe this does not need to be stated, I am fine with > that. > > olivier > --001a114214782f79f90541f7f866 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 23, 2016 at 5:25 AM, Olivier Levillain &l= t;olivie= r.levillain@ssi.gouv.fr> wrote:
>> There were actually= two points in my message:
>>=C2=A0 - I was not convinced by this way of signalling a preference= without
>> enforcing it, but I understand that, if we keep supported_groups, = it
>> does not cost much and the client can safely ignore the server sen= t
>> extension;
>>=C2=A0 - however, I found strange that the specification stated tha= t the
>> client could update its view when seeing this extension, but that = it was
>> not stated in the case of an HRR where updating its views of the >> servers' preference would clearly be useful for the future. I = only
>> proposed to add the same text "The client MAY update its view= of the
>> server's preference when receiving an HRR, to avoid the extra = round trip
>> in future encounters".
>>
> This is is unsafe, because the HRR is unauthenticated. We could update= it
> after the handshake completes, but I think this is obvious enough that= it
> doesn't
> need to be stated.

Unless I am mistaken, EncryptedExtensions is not authenticated eithe= r
(even if it is sent in the same flight as the authentication messages),
so updating the client cache can not be done immediately after
interpreting the supported_groups extension.

That is intended to be covered by the following text:

<= /div>
=C2=A0 =C2=A0by the client.=C2=A0 Clients MUST NOT act upon = any information found in
=C2=A0 =C2=A0"supported_groups"= ; prior to successful completion of the handshake,
=C2=A0 =C2=A0b= ut MAY use the information learned from a successfully completed
= =C2=A0 =C2=A0handshake to change what groups they use in their "key_sh= are"
=C2=A0 =C2=A0extension in subsequent connections.
=

My point about HRR is that the client can general= ly update its opinion
based on what it successfully completed the= handshake with. This can
happen either with HRR or when it offer= ed >1 shares and the server
took one. The special case is when= supported_versions indicates a
key type you didn't use. So I= think if we wanted text around this it would
go somewhere that c= overed the general case. I'm not sure it's needed
but if = the WG feels like we should add some text, I can...

-Ekr


olivier

--001a114214782f79f90541f7f866-- From nobody Wed Nov 23 05:39:53 2016 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 23E84129A2E for ; Wed, 23 Nov 2016 05:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 Na8se-5RHwSh for ; Wed, 23 Nov 2016 05:39:51 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (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 829FC129475 for ; Wed, 23 Nov 2016 05:39:50 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id a197so78349366wmd.0 for ; Wed, 23 Nov 2016 05:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=HnDvmi8RmIzZO+wup+cC91gvbH9xgMCKkOtJ0N0AQ8A=; b=a6hx6IYEdqFZ6B8ozxyBemO75Qng9AWzGMfkg8wuVUkgmXaufQIYa3vNH5FrKrseqN 8sLrJPa4jlN/gSnGsOSUb/Sqt0yFERVTeV2Fiz2tPAR5JsQgR2LggIbViA2mkHPxpffe aSToAY4iD68gz9dILJAZcKAuZ16OLvT1MGTyo5VHeguOJ1COs9Do0/4pzOYhdr2hUb44 IONefmP68THvwAyxgFlwTZhfPoa9Z4XzXcHMpvixrtAsiP4MS9F0SHiG5i4y/KAtYWse yFlwNgxVr6ZaHSQ33skg3PILYD/+wtQ5NiWDgjpQfFQDBxAK0CRWUpgJ0uNryzkx4KCF WWXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=HnDvmi8RmIzZO+wup+cC91gvbH9xgMCKkOtJ0N0AQ8A=; b=K3OZJ1ItDXCRK6npoxzO1wvHY+fsE+Z8mQ349tGunyj5OsZUdtbUjkkr/Xdyg556yx FcoPEQxEBuDi42B6MlHNy0DSJStPzG1QLSTmWoxtFr95kEyuOA6ab9Dw9Xj5b4uVH2UW 2fEC6tlmmTdWv+LvtHPsQO1zoGZC5X0DlGrSxmkgQWKNzji0SP4NfCPCQBmoJDAkWLDL A2c5TBtTMqVke4IZrUBjvp3NlONL1Dk1rRWlP1b3OsX87iNTF18+tVYM7EtX/OXNdKwp xidd+99h+/b1ZsVXR/k3MD6ufvLNvAIB6XFBRm166vtSLNMsudebJhf0V9ubUNCjT5HW DiCA== X-Gm-Message-State: AKaTC00JnQ4XXzWY8tLPc8S6TSOyGMIkauFJN2lCGnkgEGPz/kzSyWVMa1s+NG1WwSUBYw== X-Received: by 10.28.168.70 with SMTP id r67mr3264992wme.19.1479908389060; Wed, 23 Nov 2016 05:39:49 -0800 (PST) Received: from macbook-pro-2.mshome.net ([176.13.8.210]) by smtp.gmail.com with ESMTPSA id c133sm2859285wme.12.2016.11.23.05.39.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 05:39:48 -0800 (PST) From: Yoav Nir Message-Id: <91F6F914-17FB-4543-B916-F1829267B168@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_15C3651C-420A-4EA4-83F6-0E91F3D89FDF" Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) Date: Wed, 23 Nov 2016 15:39:38 +0200 In-Reply-To: To: John Mattsson References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <7462904085cc4a94914298af81157031@usma1ex-dag1mb1.msg.corp.akamai.com> <7de8f9da-8ab1-cfc2-00ad-9c91c7694174@gmail.com> <8394bafcd99344838d878b5e8cf5b524@usma1ex-dag1mb1.msg.corp.akamai.com> <8262a7bf-6c19-0a23-9d0b-8f59344444aa@gmail.com> X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "" Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 13:39:52 -0000 --Apple-Mail=_15C3651C-420A-4EA4-83F6-0E91F3D89FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 Nov 2016, at 12:22, John Mattsson = wrote: >=20 > On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer" > on behalf of = yaronf.ietf@gmail.com > wrote: >=20 >> So the key schedule changed and therefore we think cross-version = attacks >> are impossible. Have we also analyzed other protocols to ensure that >> cross protocol attacks, e.g. with SSH or IPsec, are out of the = question? >>=20 >> Put differently, algorithm designers gave us a cheap, easy to use = tool >> to avoid a class of potential attacks. Why are we insisting on not = using >> it? >=20 > Unless someone points out any major disadvantages with using a = context, I > agree with Yaron. I=E2=80=99m not even sure what my position is on this. Specifying the = use of a context here goes against the recommendation in the CFRG draft: Contexts SHOULD NOT be used opportunistically, as that kind of use is very error-prone. If contexts are used, one SHOULD require all signature schemes available for use in that purpose support contexts. If someone knows why this recommendation was made, that would be great. However, three working groups are currently faced with this same = decision: TLS, IPsecME and Curdle. I think it would be weird if these = three groups came up with different answers to what is essentially the = same question. At least for TLS and IKE there are no operational = differences either.=20 So Curdle, I=E2=80=99ve been told, is leaning towards empty context for = Ed448 and no OID for Ed25519ctx. IPsecME has a thread similar to this = one (with similar participants=E2=80=A6) Yoav --Apple-Mail=_15C3651C-420A-4EA4-83F6-0E91F3D89FDF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 23 Nov 2016, at 12:22, John Mattsson <john.mattsson@ericsson.com> wrote:

On 2016-11-21, 06:31, "TLS on behalf of Yaron = Sheffer"
<tls-bounces@ietf.org on behalf of yaronf.ietf@gmail.com> wrote:

So the key schedule changed = and therefore we think cross-version attacks
are = impossible. Have we also analyzed other protocols to ensure that
cross protocol attacks, e.g. with SSH or IPsec, are out of = the question?

Put differently, algorithm = designers gave us a cheap, easy to use tool
to avoid a = class of potential attacks. Why are we insisting on not using
it?

Unless someone points out any = major disadvantages with using a context, I
agree with Yaron.

I=E2=80=99m not even sure what my position is on this. = Specifying the use of a context here goes against the recommendation in = the CFRG draft:

      Contexts SHOULD NOT be used =
opportunistically, as that kind of use
      is very error-prone.  If contexts are used, one SHOULD require all
      signature schemes available for use in that purpose support
      contexts.

If someone knows why this recommendation was made, that would = be great.

However, three working groups are currently faced with this = same decision: TLS, IPsecME and Curdle. I think it would be weird if = these three groups came up with different answers to what is essentially = the same question. At least for TLS and IKE there are no operational = differences either. 

So Curdle, I=E2=80=99ve been told, is leaning towards empty = context for Ed448 and no OID for Ed25519ctx. IPsecME has a thread = similar to this one (with similar participants=E2=80=A6)

Yoav

= --Apple-Mail=_15C3651C-420A-4EA4-83F6-0E91F3D89FDF-- From nobody Wed Nov 23 06:37:58 2016 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 A610D12989C for ; Wed, 23 Nov 2016 06:37:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 UFJumxVP3Ovt for ; Wed, 23 Nov 2016 06:37:54 -0800 (PST) Received: from drew.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 574D11299E5 for ; Wed, 23 Nov 2016 06:37:53 -0800 (PST) Received: from [192.168.1.109] (p508F1333.dip0.t-ipconnect.de [80.143.19.51]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id 6BCB171E3F8E9; Wed, 23 Nov 2016 15:37:49 +0100 (CET) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Michael Tuexen In-Reply-To: <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> Date: Wed, 23 Nov 2016 15:37:47 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 14:37:56 -0000 > On 23 Nov 2016, at 09:50, Yoav Nir wrote: >=20 >=20 > On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos = wrote: >=20 >> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >>> Hi, Nikos >>>=20 >>> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos >>> wrote: >>>=20 >>>>=20 >>>> Hi, >>>> Up to the current draft of TLS1.3 the record layer is restricted >>>> to >>>> sending 2^14 or less. Is the 2^14 number something we want to >>>> preserve? >>>> 16kb used to be a lot, but today if one wants to do fast data >>>> transfers >>>> most likely he would prefer to use larger blocks. Given that the >>>> length >>>> field allows for sizes up to 2^16, shouldn't the draft allow for >>>> 2^16- >>>> 1024 as maximum? >>>=20 >>> I am not opposed to this, but looking at real browsers and servers,=20= >>> we see that they tend to set the size of records to fit IP packets.=20= >>=20 >> IP packets can carry up to 64kb of data. I believe you may be = referring >> to ethernet MTU sizes. >=20 > I=E2=80=99m referring to the IP packets that they actually use, and = that is set by TCP to fit the PMTU, which is <=3D the ethernet MTU. In = practice it is 1500 bytes for most network paths. >=20 >> That to my understanding is a way to reduce >> latency in contrast to cpu costs. An increase to packet size targets >> bandwidth rather than latency (speed). >=20 > Sure, but running =E2=80=98openssl speed=E2=80=99 on either = aes-128-cbc or hmac or sha256 (there=E2=80=99s no test for AES-GCM or = ChaCha-poly) you get smallish differences in terms of kilobytes per = second between 1024-byte buffers and 8192-byte buffers. And the = difference going to be even smaller going to 16KB buffers, let alone = 64KB buffers. >=20 >>> The gains from increasing the size of records from the ~1460 bytes >>> that fit in a packet to nearly 64KB are not all that great, and the >>> gains from increasing records from 16 KB to 64KB are almost >>> negligible. At that size the block encryption dominates the CPU = time. >>=20 >> Do you have measurements to support that? I'm quite surprized by such = a >> general statement because packetization itself is a non-negligible = cost >> especially when encryption is fast (i.e., in most modern CPUs with >> dedicated instructions). >=20 > As long as you run over a network that has a smallish MTU, you=E2=80=99r= e going to incur the packetization costs anyway, either in your code or = in operating system code. If you have a 1.44 GB file you want to send, = it=E2=80=99s going to take a million IP packets either way and 100 = million AES block operations.=20 >=20 > Whether you do the encryption is a million 1440-byte records or = 100,000 14,400-byte records makes a difference of only a few percent. >=20 > Measurement that we=E2=80=99ve made bear this out. They=E2=80=99re = with IPsec, so it=E2=80=99s fragmentation rather than packetization, but = I don=E2=80=99t think that should make much of a difference. >=20 > Again, I=E2=80=99m not opposed to this. A few percent is a worthy = gain. OK. However it would be useful to have the possibility to use a larger = record than 16 KB. This is not relevant when using TLS over TCP for which the application does not expect record = boundary preservation. For DTLS the story is different. The application expects record boundary = preservation. Therefore the maximum DTLS record size does limit the maximum message size the application can transfer. = In the case of DTLS over UDP, this is not so critical as long as you avoid IP fragmentation and have MTUs = smaller than 16 KB. However, in the case of DTLS over SCTP this imposes a limitation. SCTP does segmentation = and reassembly and therefore the MTU limit does not apply. Diameter is a protocol possibly using = DTLS/SCTP as its transport and I was told that the 16 KB limit is a real restriction in some cases, relaxing = it to 64 KB would be fine for them. So I'm not saying we need to change the default to 64 KB, we can put it = wherever you find appropriate, as long as both sides can negotiate a larger limit. For example, one could allow the Maximum Fragment Length Negotiation to = negotiate a value larger then 16KB. You would only need to extend the enum in https://tools.ietf.org/html/rfc6066#section-4 to allow values larger than 2^14. Best regards Michael >=20 > Yoav >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Nov 23 07:51:29 2016 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 253D7129E8D for ; Wed, 23 Nov 2016 07:51:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 HsQlp0c8O9JG for ; Wed, 23 Nov 2016 07:51:25 -0800 (PST) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 5B398129E9C for ; Wed, 23 Nov 2016 07:50:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 95DF3142E6; Wed, 23 Nov 2016 17:50:53 +0200 (EET) X-Virus-Scanned: Debian amavisd-new at pp.htv.fi Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id oIGXTQF6B0xh; Wed, 23 Nov 2016 17:50:53 +0200 (EET) Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 1D0D521C; Wed, 23 Nov 2016 17:50:53 +0200 (EET) Date: Wed, 23 Nov 2016 17:50:47 +0200 From: Ilari Liusvaara To: Yoav Nir Message-ID: <20161123155047.GA30446@LK-Perkele-V2.elisa-laajakaista.fi> References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <7462904085cc4a94914298af81157031@usma1ex-dag1mb1.msg.corp.akamai.com> <7de8f9da-8ab1-cfc2-00ad-9c91c7694174@gmail.com> <8394bafcd99344838d878b5e8cf5b524@usma1ex-dag1mb1.msg.corp.akamai.com> <8262a7bf-6c19-0a23-9d0b-8f59344444aa@gmail.com> <91F6F914-17FB-4543-B916-F1829267B168@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <91F6F914-17FB-4543-B916-F1829267B168@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Cc: "" Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 15:51:28 -0000 On Wed, Nov 23, 2016 at 03:39:38PM +0200, Yoav Nir wrote: > > > On 23 Nov 2016, at 12:22, John Mattsson wrote: > > > > On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer" > > on behalf of yaronf.ietf@gmail.com > wrote: > > > >> So the key schedule changed and therefore we think cross-version attacks > >> are impossible. Have we also analyzed other protocols to ensure that > >> cross protocol attacks, e.g. with SSH or IPsec, are out of the question? > >> > >> Put differently, algorithm designers gave us a cheap, easy to use tool > >> to avoid a class of potential attacks. Why are we insisting on not using > >> it? > > > > Unless someone points out any major disadvantages with using a context, I > > agree with Yaron. > > I’m not even sure what my position is on this. Specifying the use of a > context here goes against the recommendation in the CFRG draft: > > Contexts SHOULD NOT be used opportunistically, as that kind of use > is very error-prone. If contexts are used, one SHOULD require all > signature schemes available for use in that purpose support > contexts. > > If someone knows why this recommendation was made, that would be great. Basically, then those other methods would be a weak point for attack. Then there's the serious deployment problems with contexts, as those don't fit into any standard notion of signature various libraries have. -Ilari From nobody Wed Nov 23 08:01:58 2016 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 88622129534 for ; Wed, 23 Nov 2016 08:01:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0YzPETt-fXG for ; Wed, 23 Nov 2016 08:01:56 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 DF6F71295F0 for ; Wed, 23 Nov 2016 08:01:51 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id t79so30074615wmt.0 for ; Wed, 23 Nov 2016 08:01:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=frb1XO8vqc7MTDmcEAe7Prp6ncZYXQDHtEPwD4UelAg=; b=q6PbHv5H5FWWjrQue4FK2laDtIf3fiV5HaBNc9z2flYABJJdoliNQMXl3UulSjuo27 rRJ3FLXfZJQEU8DN1ml9j1wLLvRW9l9z3iB8E9HvtIqPVbBiO4J/1ipZLgEgTwodPNt9 XAZQ3u6una+5YiVGUP4u8qJe75fG/crim3Z7f0zM13vH+q54PE6QfvhebiPlcm7VW3L5 kYhyRjRS8deMUHYPJqtt5NkgpZmy50qmrDGijIOTEBVGe5vKYU6On+D0I2no6izqpScY v2UUNH3Evm1Yj5J1bsqFhyp8hvS3Ar5S6AHk0oEpmHLiTSA5wm0PNJZq4X3+AtzIh1LB 9piQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=frb1XO8vqc7MTDmcEAe7Prp6ncZYXQDHtEPwD4UelAg=; b=fdugOsevoNLGp+PATvU0Y7Eq/PKws8nY7eC+ubo83qfeHShEXdo98ohD6pfc/Ngi7q /5/gAXZyg+SUe73dewxieRsbNgYo/zdnOda605PJs/EZwgSDciyMubo6bKKtM8GFPS2N Ay/IZH6nnoKzapg/IxP325TT8dQGHE+dVO+ESPG6PPUr0gFJHSQfdy7NoBS6VfxX6sMD BOORCA+w0+9I9nrOos1kjeon3XADQHMVTEcY4uIJNcomf38uoEADzN9p8AvzhC3E0dUL 8NhnxPExUSBRzzzy6SdBG/QuPRXyn9eyMAcOYuk5zudIaCMHrrQw+DDTJ6Jl6xPdVKSL gfug== X-Gm-Message-State: AKaTC01CY4WB9vwbEJHZrENWQ/97VhYX9QZQlo1j6merntiqxaTtyCMx1zX+slCrdqLMtA== X-Received: by 10.28.48.145 with SMTP id w139mr8230514wmw.113.1479916910400; Wed, 23 Nov 2016 08:01:50 -0800 (PST) Received: from [172.18.133.122] (cowboy.intuit.com. [65.204.229.11]) by smtp.gmail.com with ESMTPSA id t84sm3465359wmt.7.2016.11.23.08.01.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Nov 2016 08:01:49 -0800 (PST) To: Ilari Liusvaara , Yoav Nir References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <7462904085cc4a94914298af81157031@usma1ex-dag1mb1.msg.corp.akamai.com> <7de8f9da-8ab1-cfc2-00ad-9c91c7694174@gmail.com> <8394bafcd99344838d878b5e8cf5b524@usma1ex-dag1mb1.msg.corp.akamai.com> <8262a7bf-6c19-0a23-9d0b-8f59344444aa@gmail.com> <91F6F914-17FB-4543-B916-F1829267B168@gmail.com> <20161123155047.GA30446@LK-Perkele-V2.elisa-laajakaista.fi> From: Yaron Sheffer Message-ID: Date: Wed, 23 Nov 2016 18:01:44 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161123155047.GA30446@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: "" Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 16:01:57 -0000 >> >> I’m not even sure what my position is on this. Specifying the use of a >> context here goes against the recommendation in the CFRG draft: >> >> Contexts SHOULD NOT be used opportunistically, as that kind of use >> is very error-prone. If contexts are used, one SHOULD require all >> signature schemes available for use in that purpose support >> contexts. >> >> If someone knows why this recommendation was made, that would be great. > > Basically, then those other methods would be a weak point for attack. > But we are trying to migrate away from the old methods, into the new methods. The fewer servers use the old methods, the better off we are, right? So we expect the attack surface to gradually be reduced over the coming years. > > > Then there's the serious deployment problems with contexts, as those > don't fit into any standard notion of signature various libraries have. > These are new algorithms that are still not widely deployed. The fact that several open source libraries (still) don't support a certain function parameter is not a very strong reason not to require it. Thanks, Yaron From nobody Wed Nov 23 09:03:01 2016 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 57CE712A04F for ; Wed, 23 Nov 2016 09:03:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.398 X-Spam-Level: X-Spam-Status: No, score=-3.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 341XajmPrfkX for ; Wed, 23 Nov 2016 09:02:56 -0800 (PST) Received: from smtp.ssi.gouv.fr (smtp.ssi.gouv.fr [86.65.182.16]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B5D512A059 for ; Wed, 23 Nov 2016 09:02:55 -0800 (PST) Received: from smtp-switch.internet.local (smtp-switch [192.168.3.9]) by smtp.ssi.gouv.fr (Postfix) with ESMTP id 9FF8090B949; Wed, 23 Nov 2016 18:02:54 +0100 (CET) References: <20161122190758.GG19978@neoplankton.picty.org> From: Olivier Levillain X-Enigmail-Draft-Status: N1110 To: Eric Rescorla Message-ID: <5835CBBE.9070202@ssi.gouv.fr> Date: Wed, 23 Nov 2016 18:02:54 +0100 User-Agent: MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Message order X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 17:03:00 -0000 Hi, > On Tue, Nov 22, 2016 at 11:08 AM, Olivier Levillain < > olivier.levillain@ssi.gouv.fr> wrote: > >> = Message order = >> >> I believe the message P.27 section 4 is important, but not >> sufficient. As already expressed on the list, a formal automaton >> should be provided in the spec. >> >> I think Ekr said there was some work in progress in this area. Is >> this a goal for the final specification? >> > Yes, I will put some sort of more complete state machine in the final spec > (probably in -19) I have been working on my black board on the simplest case (pure TLS, no PSK support), and I stumble upon the late client authentication issue that was presented in the thread starting with https://www.ietf.org/mail-archive/web/tls/current/msg21500.html. I agree with the thread that NST and KU are easy to deal with. As stated in the thread, as it is currently specified, the mechanism is kind of a pandora's box : - the client must keep the handshake transcript (or its running / forkable hash) because of the Finished message that must eventually be sent - the server can send multiple CertificateRequest, and the client must, for each, keep the content of the message (for the label, and also for the hash context required for the Finished message) => the unboundedness problem - there is no way to reject the request gracefully. As I understand the thread, one idea was to say that the mechanism is forbidden by default, unless it is activated by some profile. However, as stated in https://www.ietf.org/mail-archive/web/tls/current/msg21561.html, since there are voices to allow it in the HTTP profile, this is problematic because HTTPS can be used in constrained environments where we would like to avoid late client auth. I believe the late client auth mechanism should explicitly be negotiated, either at the TLS level with an extension, or at the application level via an API callback (not a profile) and an upper layer nego. Sorry to dig this up (and sorry for the re-discovery explained at length), but where does the WG stand on this issue? PR 680 is currently parked, but I believe the current situation is not acceptable from the client's point of view, and I fail to see whether unbounded parallel certificate requests would be used in practice or not. Best regards, olivier From nobody Wed Nov 23 09:49:39 2016 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 9154512A1B4 for ; Wed, 23 Nov 2016 09:49:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 yAKEm---no8S for ; Wed, 23 Nov 2016 09:49:37 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 7782712A1FF for ; Wed, 23 Nov 2016 09:47:55 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id a10so17883105ywa.3 for ; Wed, 23 Nov 2016 09:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=vic8M4MTETn6Fm/juHqnZyI4qsVMQ60sAm63L39y9OE=; b=ALfu5P4UPKWc+kyBZ4CFBfmLsF+zCgFS4i0yEpzgyzxKcI+AwcIYMNGievW2ertFEN eEKqFjb7SWtibqZ6AGzf/XXO+iYlhz/Wttz2YtR4yVR4EYWscjua4j4d9RLsDSqtw9Yy d2VXc2RaOkrJbuwMZxykjLYpFCHVyKG21PPLhtS5go2uE6g4qc0iNEB1S4w3GAx0l5ZN KrHr8VgSx3vSt+eHLQWKxnm/0LzOQi/ag6DkLVl2bLZichiKGEWbwaZnRbZnLFqR0IQ0 3HK0pTVWNGcrBShKLFjVq37G1wAf79fmwwmv2lYyR4/bsjNNlPibGMaQE2RJt5NnbTkw Fyag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=vic8M4MTETn6Fm/juHqnZyI4qsVMQ60sAm63L39y9OE=; b=hNPdYykrnB3bMBfSo0Ve8dx5Js9Ro4T1VUduLV1Xwujuz9zzCQiGTlP6+jcixN/mCa AL2Tsg6DwBb3z4c4v3mRqvYjbTGH1OYoRhIKsn8j4mN+aZveMfnUGdhf0Eu4vRU6PcfI Wf+LVbl1dUyWXWBRQNsAQ2VSXMKMj67oWoNjUSamg+5VnuM1HQibdB9XT6E4kz/XJXa8 NaQY9eSENokmCzQe+gtoc7DwNGPLzem3oDgEQM14YLehTp/Rom4kHbPKJdgimm8CO9dE 6TQQkiH43xgHoHA/UvXesC1Yct0/ZfdWzDh8hi1GSJEfEcEAMB8jpb/tFsNDSHaugbKI 1SvQ== X-Gm-Message-State: AKaTC00nVkswN77ur+4/QXEoM0zRubRK+R4/hkxyGFyHBAzYGXI9H7WMp7O3/0uXDdvKJrgSwD6oK6H6BX7Psg== X-Received: by 10.129.122.17 with SMTP id v17mr4722126ywc.67.1479923274528; Wed, 23 Nov 2016 09:47:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.115.3 with HTTP; Wed, 23 Nov 2016 09:47:54 -0800 (PST) From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 23 Nov 2016 09:47:54 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c07b4a01308770541fb7d22 Archived-At: Subject: [TLS] Additional warnings on 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 17:49:38 -0000 --94eb2c07b4a01308770541fb7d22 Content-Type: text/plain; charset=UTF-8 I've submitted a PR with an expanded warning on the dangers of 0-RTT data for implementors: https://github.com/tlswg/tls13-spec/pull/776/files The text is there, and the TLDR summary is basically that time-based defenses aren't sufficient to mitigate idempotency bugs, so applications need to be aware of the sharp edges and have a plan. For clarity, I've outlined three example security issues that could arise due to realistic and straightforward, but naive, use of 0-RTT. There's been some light discussion of each in person and on the list. In the PR I'm "MUST"ing that applications need to include /some/ mitigation for issues of this class (or else they are obviously insecure). In my experience this class of issue is so pernicious, and easy to overlook, that I'm also "RECOMMEND"ing that applications using Zero-RTT data *intentionally* replay 0-RTT data non-deterministically, so as to keep themselves honest. At a bare minimum I think it would be good to make clear that clients and implementations MAY intentionally replay 0-RTT data; to keep servers on their toes. For example a browser could infrequently tack on a dummy connection with repeated 0-RTT data, or an implementation could periodically spoof a 0-RTT section to the application. That should never be considered a bug. but a feature. (And to be clear: I want to do this in our implementation). -- Colm --94eb2c07b4a01308770541fb7d22 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I've submitted a PR with an expand= ed warning on the dangers of 0-RTT data for implementors:


=
The text is there, and the TLDR summary is basically that time-based d= efenses aren't sufficient to mitigate idempotency bugs, so applications= need to be aware of the sharp edges and have a plan.=C2=A0 For clarity, I&= #39;ve outlined three example security issues that could arise due to reali= stic and straightforward, but naive, use of 0-RTT. There's been some li= ght discussion of each in person and on the list. =C2=A0

In the PR I'm "MUST"ing that applications need to incl= ude /some/ mitigation for issues of this class (or else they are obviously = insecure). In my experience this class of issue is so pernicious, and easy = to overlook, that I'm also "RECOMMEND"ing that applications u= sing Zero-RTT data *intentionally* replay 0-RTT data non-deterministically,= so as to keep themselves honest.=C2=A0

At a bare = minimum I think it would be good to make clear that clients and implementat= ions MAY intentionally replay 0-RTT data; to keep servers on their toes. Fo= r example a browser could infrequently tack on a dummy connection with repe= ated 0-RTT data, or an implementation could periodically spoof a 0-RTT sect= ion to the application. That should never be considered a bug. but a featur= e. (And to be clear: I want to do this in our implementation).=C2=A0
<= br clear=3D"all">

--
Colm<= /div>
--94eb2c07b4a01308770541fb7d22-- From nobody Wed Nov 23 09:55:53 2016 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 8E8D312A261 for ; Wed, 23 Nov 2016 09:55:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sn3rd.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 AyLKClhNjxlF for ; Wed, 23 Nov 2016 09:55:51 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (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 37AFD12A286 for ; Wed, 23 Nov 2016 09:54:49 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id n6so18755707qtd.1 for ; Wed, 23 Nov 2016 09:54:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KUSn3xvHYPGzdxaH7ntjtgMxy5NlJidigMXoL6c/CU4=; b=IzJshtfC0iL8K8sf1i7OK9cENMOek9fr3MphwDcfuady9fSLS++vp7ILLeow3+75WS zK8ZoFji6M+EvKoe1VAulRucGJ2DcHOTRef8c2Ay9N+oSRsNBrVvmQaKxqtB1cZe4Ixt lHE+ToIFdkDpJpW/U4/Z5B3253PdV0gnCWU8U= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KUSn3xvHYPGzdxaH7ntjtgMxy5NlJidigMXoL6c/CU4=; b=O3y4iyLMr3HwI7UvVxmKGkvksdpDSMZofgWr77+BOkwePl3ifUY5XxGGBHetC5oPd2 UHLXCncYF2zON2XyHZnN8HAAYZ/bejPPuGveNs/6rfpn+DjDAJF1r8hMCmtLA4bh1I5i d3tuJoh3OqrwIvQiDPjjhMVXxoX7FHSPyBZM0KTc2IiCcNhWISO7psFz4q7gxPeo79PJ /pt2Sy8Z6HXTFvJlL1Ko+3aP8NHTxfl1HmUgvLCzVmxtxrREbtLx+9jjjh1otlVH9ObE jzpTrbwP8mA0ECVEAkKR7mClA4cGNkGpSWPEK4nX0kcifnw2GJzZNoTVY6pZQOMU30l4 uV9w== X-Gm-Message-State: AKaTC017w9ENXDnKqMk6Xk+uTL2OhpwuFaJt+EqpaCJ0bKZ1c7w4GHTmFU8oy8AIRAfvmA== X-Received: by 10.200.55.61 with SMTP id o58mr3681806qtb.6.1479923688405; Wed, 23 Nov 2016 09:54:48 -0800 (PST) Received: from [172.16.0.92] ([96.231.230.70]) by smtp.gmail.com with ESMTPSA id d84sm2806928qkc.33.2016.11.23.09.54.47 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 23 Nov 2016 09:54:47 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Sean Turner In-Reply-To: <48C23517-6EFD-4A3C-A020-9CC1A87469B8@gmail.com> Date: Wed, 23 Nov 2016 12:54:46 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <62B88142-2DBE-439F-AD4A-309053925794@sn3rd.com> <48C23517-6EFD-4A3C-A020-9CC1A87469B8@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "" Subject: Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 17:55:52 -0000 >> - Section 1 >> "This is illustrated in the following table, based on = [Lenstra_Verheul], >> which gives approximate comparable key sizes for symmetric- and >> asymmetric-key cryptosystems based on the best-known algorithms for >> attacking them." >>=20 >> The key sizes for DH/DSA/RSA does not seem to be based on the >> Lenstra-Verheuls equations which gives much higher key sizes for >> DH/DSA/RSA. >>=20 >> The DH/DSA/RSA key sizes seem to be based on NIST recommendations. I >> suggest either: >>=20 >> A) Fully based the table on NIST recommendation, which means keeping >> DH/DSA/RSA as is but simplifying ECC to 2 * Symmetric. >> B) Update the DH/DSA/RSA key sizes based on state-of-the-art. But = then I >> would say that this is not [Lenstra_Verheul], but rather [RFC3766], >> [Lenstra 2004], [ECRYPT 2012]. I think these three all use the same >> equation. >> C) Just remove DH/DSA/RSA as the draft is about ECC. >=20 > I=E2=80=99m inclined to get rid of this table and all the text from = =E2=80=9CThis is illustrated=E2=80=A6=E2=80=9D entirely. ECC is by now = in wide use. We don=E2=80=99t need to =E2=80=9Csell=E2=80=9D it any = more. so unless someone would like to make a PR with better text, I will = just get rid of it. You could be more draconian and start the draft with the paragraph: This document describes additions to TLS to support ECC =E2=80=A6. Because you=E2=80=99re right we don=E2=80=99t really need to do much = selling here. spt= From nobody Wed Nov 23 10:22:23 2016 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 3065712A2C2 for ; Wed, 23 Nov 2016 10:22:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 EgqD3Z-X_AUH for ; Wed, 23 Nov 2016 10:22:09 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 705A8129A6C for ; Wed, 23 Nov 2016 10:22:08 -0800 (PST) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87_RC123) id 1c9cBI-0005Vk-JY for tls@ietf.org (return-path ); Wed, 23 Nov 2016 18:22:04 +0000 To: tls@ietf.org References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> From: Jeremy Harris Message-ID: <66c428f3-33a9-3a19-7ec7-b090d6a3831a@wizmail.org> Date: Wed, 23 Nov 2016 18:22:01 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 18:22:22 -0000 On 23/11/16 08:50, Yoav Nir wrote: > As long as you run over a network that has a smallish MTU, you’re going to incur the packetization costs anyway, either in your code or in operating system code. If you have a 1.44 GB file you want to send, it’s going to take a million IP packets either way and 100 million AES block operations. Actually, no. Everybody offloads ether-frame packetization and TCP re-segmentation to the NIC, talking 64kB TCP segments across the NIC/OS boundary. Precisely because of the packetization cost. -- Jeremy From nobody Wed Nov 23 11:14:27 2016 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 E3F89129B41 for ; Wed, 23 Nov 2016 11:14:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.019 X-Spam-Level: X-Spam-Status: No, score=-2.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3F82hu03xcZk for ; Wed, 23 Nov 2016 11:14:25 -0800 (PST) Received: from mail-ua0-f181.google.com (mail-ua0-f181.google.com [209.85.217.181]) (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 DDB11129AFD for ; Wed, 23 Nov 2016 11:14:24 -0800 (PST) Received: by mail-ua0-f181.google.com with SMTP id b35so23912581uaa.3 for ; Wed, 23 Nov 2016 11:14:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mght2cCSG3AIH/q+o8qRHsQcXn3k4kh7Tht7k35ztps=; b=X42wj+QbCDbfgEP8C889xgkwZ0KIBSvY/BUQF8rYxaiFvVIMfawjBENy3p+9EeZxyq ruZim+UAFlkjSckyhIEz7C7fhuoHdsbxO1VTbxfQBgZ2KD7cYLAvq5eZYbMNApIdHsgU CNaaLBi/DY1Xernwx7awt+npoFxxDS++CWp5MPKqbSJRSgOuzhNKbAAp+RZrMNJiFc/l TUPAjzDDEktY6lw/A5TMG9EBbqibCdtBRUBPUrGP9cRvFywrln1QJwm0ATtYhwHRznOO Ae5rVUsojj6NH8fZD7TZHwcZVcC821wM3UMAvH6ZY3GGVM2iXHruAKj6fZ54UrTcPrSr 9vkg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mght2cCSG3AIH/q+o8qRHsQcXn3k4kh7Tht7k35ztps=; b=Mt5WfpVIsOObrNlbMJ8H34Scd4kxcy9EQF+ke4eEcuKwOTjyVajILtxpSMYAaPoTC8 Efd9JtfihvSSfgmC5G9xMz0fQJK0A/Ij58TEZuAIqXf5goF8icYF20NcdtiNXz8woNCj obQ9fzTruFtqeHNEhfc6zFl7NkLBBHyiP5tV1+mZ8rPOpQK3cLGjwPpLIyXRyiE/JdXd +sldzzAudv1nCzDcWMZvdZNenVT24eJRLAwqfpY5LfsIHysBSxuas1iMYP3iZpr0B/GT OhZ9Vrsd7thDnfNgQAvKZWvyyTThz6qHdBG4wNIx0RIkziHjl1LzwpHJOTgdiDMsc/LX 45dw== X-Gm-Message-State: AKaTC02AhW2KfqSEVGXmq51DoCAXdTOpxYOIY2UdZS1QFGeAfETxYLY69MM2Iiace11eGI6fTyDAhFZzqdh3qQ== X-Received: by 10.176.3.84 with SMTP id 78mr3360887uat.117.1479928403857; Wed, 23 Nov 2016 11:13:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.176.85.18 with HTTP; Wed, 23 Nov 2016 11:13:23 -0800 (PST) Received: by 10.176.85.18 with HTTP; Wed, 23 Nov 2016 11:13:23 -0800 (PST) In-Reply-To: <66c428f3-33a9-3a19-7ec7-b090d6a3831a@wizmail.org> References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> <66c428f3-33a9-3a19-7ec7-b090d6a3831a@wizmail.org> From: Watson Ladd Date: Wed, 23 Nov 2016 11:13:23 -0800 Message-ID: To: Jeremy Harris Content-Type: multipart/alternative; boundary=001a113f0326ce18010541fcaeb5 Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 19:14:27 -0000 --001a113f0326ce18010541fcaeb5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Nov 23, 2016 10:22 AM, "Jeremy Harris" wrote: > > On 23/11/16 08:50, Yoav Nir wrote: > > As long as you run over a network that has a smallish MTU, you=E2=80=99= re going to incur the packetization costs anyway, either in your code or in operating system code. If you have a 1.44 GB file you want to send, it=E2= =80=99s going to take a million IP packets either way and 100 million AES block operations. > > Actually, no. Everybody offloads ether-frame packetization and TCP > re-segmentation to the NIC, talking 64kB TCP segments across the NIC/OS > boundary. Who is 'everybody'? Let's look at the cost more exactly. We always have to copy from the storage to the network. Packetization copies a tiny bit more data on each packet. Maybe if you have special PCI DMA between devices, but that is rare= . > > Precisely because of the packetization cost. > -- > Jeremy > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --001a113f0326ce18010541fcaeb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Nov 23, 2016 10:22 AM, "Jeremy Harris" <jgh@wizmail.org> wrote:
>
> On 23/11/16 08:50, Yoav Nir wrote:
> > As long as you run over a network that has a smallish MTU, you=E2= =80=99re going to incur the packetization costs anyway, either in your code= or in operating system code. If you have a 1.44 GB file you want to send, = it=E2=80=99s going to take a million IP packets either way and 100 million = AES block operations.
>
> Actually, no.=C2=A0 Everybody offloads ether-frame packetization and T= CP
> re-segmentation to the NIC, talking 64kB TCP segments across the NIC/O= S
> boundary.

Who is 'everybody'?

Let's look at the cost more exactly. We always have to c= opy from the storage to the network. Packetization copies a tiny bit more d= ata on each packet. Maybe if you have special PCI DMA between devices, but = that is rare.

>
> Precisely because of the packetization cost.
> --
> Jeremy
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--001a113f0326ce18010541fcaeb5-- From nobody Wed Nov 23 14:46:24 2016 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 60AB012949E for ; Wed, 23 Nov 2016 14:46:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] 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 FB83pJHeF0MH for ; Wed, 23 Nov 2016 14:46:20 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (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 B357C12940F for ; Wed, 23 Nov 2016 14:46:20 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id n6so25323759qtd.1 for ; Wed, 23 Nov 2016 14:46:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=FI/6A3Z2M43lP2muCYcLQj2nOjmHQB69bRgqeFDhgTg=; b=dAkAbPxVKcBs5fWBw646fBQGmJn/kdp2DlcaUfp35oBg2ngU8IDM8e3dGd8RJn/tcE IvsI/GZWRFaVrN2UIucHbh2BZq1hHk74NmcTimvBxmyNSaglxtjFRVi/6jJ/xCoBoTk7 IKMKGzQu0wWrj4AmJZ15NWPRqxHnwCZsuqwG8RcV7tm9lWuk/rms+EXuTRzNhorb5pAD RyVV8Hs/EgTwWPBjSArfLVuIAjt041rfOKx1Xrp2ylim9qTWFDn81oJUJTl1XlETuT7K aUwsF624JSklnFFZQ7hbQimvanHrXbpAdrS0Oate4Ix3r/ZgpZ6dL4jPDXQUzdQNx84d LS4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FI/6A3Z2M43lP2muCYcLQj2nOjmHQB69bRgqeFDhgTg=; b=DBW1LwQJ0v6HbYVdPozozSVJc6bj69YZBGodIssb0fLWLkvzHll7My9yd03h/OafdQ 9AZZYFtBVHyShr49eTq78dD2VMKVQ3UIWNTl0GqdCYf3rEvj2q7AHeMS8IL4nrgYO0VJ yRmnLloMJgbnNQH9dndnzrUxGTWCk69I9BgOpuw/mcotrKABFvOEDouVaV87Qjcn2f5i UjKuk5PYbidl3t5iYjmTCH3RmZfKt+Ib7rrbUj+Ne3MjZpeme3HfiLfZxuXHbMBNoxBk 2TqKQyIKDAPk0573ebFv5wS5raZ9yD2KKMNL83tHICjtvKOPWmtLDrGx1ylpyoFSEHZd C9aA== X-Gm-Message-State: AKaTC012mF17kAxIrUcZXuwuIghUerqS18IbhmC5Z5fjR3kp7PcHn1wohB52yJDDIvgqDfE/x9DE5ugKZl3W8KXa X-Received: by 10.237.53.56 with SMTP id a53mr4637979qte.85.1479941179645; Wed, 23 Nov 2016 14:46:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.157.11 with HTTP; Wed, 23 Nov 2016 14:46:19 -0800 (PST) In-Reply-To: References: <4e2b054a-c391-d4f9-c106-d62eb90e2034@akamai.com> From: Victor Vasiliev Date: Wed, 23 Nov 2016 17:46:19 -0500 Message-ID: To: Benjamin Kaduk Content-Type: multipart/alternative; boundary=001a11c0302a4d7fbc0541ffa831 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SNI and Resumption/0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 22:46:22 -0000 --001a11c0302a4d7fbc0541ffa831 Content-Type: text/plain; charset=UTF-8 It seems that this issue has not been so far successfully resolved, and to the best of my knowledge it has not been discussed during the meeting in Seoul. I still believe that this is a valuable feature, and our experience with 0-RTT handshake deployment in QUIC has indicated that it's basically required to make 0-RTT work for YouTube videos. So far, we have considered three options in this thread: (1) Retain RFC 6066 restriction on SNI, (2) Allow resumption for different SNI provided it was negotiated in the ticket, (3) Always allow resumption for different SNI. In both (2) and (3), the certificate for the original ticket issuer would have to be valid for the new server name, of course. I believe that (2) will result in a higher resumption success rate than (3), since for the servers that do not support shared resumption key, (3) would result in losing session tickets to unsuccessful resumption. For concreteness, I wrote a pull request that describes (2): --001a11c0302a4d7fbc0541ffa831 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It s= eems that this issue has not been so far successfully resolved, and to the<= /div>
best of my knowledge it has not been discus= sed during the meeting in Seoul. =C2=A0I
st= ill believe that this is a valuable feature, and our experience with 0-RTT<= /div>
handshake deployment in QUIC has indicated = that it's basically required to make
0-= RTT work for YouTube videos.

So far, we have considered three options in this thr= ead:
=C2=A0 (1) Retain RFC 6066 restriction= on SNI,
=C2=A0 (2) Allow resumption for di= fferent SNI provided it was negotiated in the
=C2=A0 =C2=A0 =C2=A0 ticket,
=C2=A0 (3) = Always allow resumption for different SNI.
= In both (2) and (3), the certificate for the original ticket issuer would h= ave
to be valid for the new server name, of= course.

I believe that (2) will result in a higher resumption success rate than = (3),
since for the servers that do not supp= ort shared resumption key, (3) would
result= in losing session tickets to unsuccessful resumption.

For concreteness, I wrote = a pull request that describes (2):
=C2=A0 = =C2=A0 <https:/= /github.com/tlswg/tls13-spec/pull/777>
--001a11c0302a4d7fbc0541ffa831-- From nobody Wed Nov 23 15:03:22 2016 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 82DA4129435 for ; Wed, 23 Nov 2016 15:03:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHgVPG06YYZL for ; Wed, 23 Nov 2016 15:03:18 -0800 (PST) Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 100A512953C for ; Wed, 23 Nov 2016 15:03:18 -0800 (PST) Received: by mail-qk0-x234.google.com with SMTP id n204so32029199qke.2 for ; Wed, 23 Nov 2016 15:03:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=rwm/2dB9JV61dHThS2x87KE4yo8r1oNxyZT+6oZ3+ZQ=; b=r4+MfW0SxC0PrbcEghnlOvotvtan6U7EGbabv1RXgJoLOGCu7pmSvzOq8G2SfZfv9+ RAJcyGYa2+lPDFaa81dJozA77ZuYEiSjYRHqQtTgUfNt/uNo8QbLRA/tALDIK6DIJdLQ SI2LRdFLYSyk/o9XogFLQtC8sXAXpK3eErL2lN+ReWxD/cjYFU6Ugl4XW87P55n6Eghh pFSNmtPAX3gVv8ZzMFJC9SGPoGUM5YQrb/Asx02TWYdb9ooVJB/e99ajjIM1DERXWDKQ 9ZwRVbub2JsLy23LKGcNwtYhABUhoDDjVEJ2Iwv7QlAfCURXfXCpGwPQggc/aCIVCLnk CcFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=rwm/2dB9JV61dHThS2x87KE4yo8r1oNxyZT+6oZ3+ZQ=; b=FAMqHJVNa924P8CxNvCzgZRTx0qQ8sFRd7Ka3cZfIuNTDxtxiac24PtCPogKmB8j2q IHgoCEUVsTRf0v/UtlmjmPA6cr8RjXvZwxQqPCif41z9RJ/HxJXE4wmtb6xpOcp/2eoV Gp2QRxTYLI2B6bQqgXizX0eMrA2J48diQr5IMfWI7Hl++CD0zvr5yfi3wLjNzTBKup63 rLLxio+wuP74V2QRuy7YcCbFbN0Apq5Dp5Po53DjSzBuCM+NQ+Jyz9HitP6KZU1QMxhv PeahKLEVG1Obfn7VancbAFjX7hDfL7Ra8O75fMfxYlj8JOt2YFjJjjFGcYQ9angaT6YO 4PAg== X-Gm-Message-State: AKaTC00H9J0zxF6kMbOhkGl3xv+jra4lRyviAJoogPJaqJZ+Mn+AOdYKQEh/QZgNdh4YoHIkAhQGyqV0Iu13Vg== X-Received: by 10.55.184.68 with SMTP id i65mr5555067qkf.5.1479942197145; Wed, 23 Nov 2016 15:03:17 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Wed, 23 Nov 2016 15:03:16 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 24 Nov 2016 10:03:16 +1100 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Additional warnings on 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 23:03:20 -0000 This seems like too much text to me. Maybe some people would appreciate the reminder that replay might cause side-effects to be triggered multiple times, or that side effects are just effects and those might also be observable. But I think that those reminders could be provided far more succinctly. The bit that concerns me most is the recommendation to intentionally replay early data. Given that I expect that a deployment that enables 0-RTT will tolerate some amount of side-effects globally, and that excessive 0-RTT will trigger DoS measures, all you are doing is removing some of the safety margin those services operate with. On 24 November 2016 at 04:47, Colm MacC=C3=A1rthaigh wr= ote: > > I've submitted a PR with an expanded warning on the dangers of 0-RTT data > for implementors: > > https://github.com/tlswg/tls13-spec/pull/776/files > > The text is there, and the TLDR summary is basically that time-based > defenses aren't sufficient to mitigate idempotency bugs, so applications > need to be aware of the sharp edges and have a plan. For clarity, I've > outlined three example security issues that could arise due to realistic = and > straightforward, but naive, use of 0-RTT. There's been some light discuss= ion > of each in person and on the list. > > In the PR I'm "MUST"ing that applications need to include /some/ mitigati= on > for issues of this class (or else they are obviously insecure). In my > experience this class of issue is so pernicious, and easy to overlook, th= at > I'm also "RECOMMEND"ing that applications using Zero-RTT data > *intentionally* replay 0-RTT data non-deterministically, so as to keep > themselves honest. > > At a bare minimum I think it would be good to make clear that clients and > implementations MAY intentionally replay 0-RTT data; to keep servers on > their toes. For example a browser could infrequently tack on a dummy > connection with repeated 0-RTT data, or an implementation could periodica= lly > spoof a 0-RTT section to the application. That should never be considered= a > bug. but a feature. (And to be clear: I want to do this in our > implementation). > > > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Nov 23 15:10:11 2016 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 621C3129404 for ; Wed, 23 Nov 2016 15:10:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ag-Fe7XFuk3 for ; Wed, 23 Nov 2016 15:10:08 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 9554E129435 for ; Wed, 23 Nov 2016 15:10:07 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id w33so25582138qtc.3 for ; Wed, 23 Nov 2016 15:10:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=3FsYThQnOgR0ReE+YWqSuOrxTzyskKUhmK+ZmRCYR3c=; b=a904wfLBVM3Ldc/wONRF4O+Q+lYlRMCdyxA92viO8XMZfGUD1xPMZpq4aI+AljFFv6 XjtAjm13z/OQPOR9LMAl9u0Ph5m1P5/nGnAapW8wE73JdxgAaMuatrzHL1ILxWbxN9fS RONkDD1z/DavwXqkv/3G5obIc6wcErOE3Jvpz7dN+yQqLueaqsGs01Lr+/RRvyAMTRAD p2Mmhl+F6nKikz8ic/OW9z25AcHfUO/imdQ4LxIchEtYXmIXenv2hG2BGWbUaEXyIkTd OJekg1wXTLIk+K2CT9AqiX+FkfHu6r0RCN9vF2LUGkr1KvMMLliD4I1TngxdsUUBiAXL /tFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3FsYThQnOgR0ReE+YWqSuOrxTzyskKUhmK+ZmRCYR3c=; b=A1L2iSpsq8aOndqeuQWbzvslEPHdMfzCkaPGhoZKvDm0H9YQjCaV1Z+GyMS8u8Bi27 mzWOmg1tYvLEtSd7Ds9m8VA9xuUXkTmqTRV2fdXue5xRHcQsIbm8z+dUXFHEFzVw+vmc AZJ+0tnwruM5yxb/yxAsWlnizk1N986oem+mLPwmYInBcsc2+JbDbyHwmL7YzsNPW7QN 3zxmaer3KFjB0ojMvIRQHOo0ACSZmoLsxI+0BYvnUP/NUZZqw2gjVQYbORwDa8Q2l73E nJXBU3m/7DF+wPGccx357PD1am8WQjw/AylD5mHwl1nA82HFbBBNeYllacT1GGr9zcaC 6brA== X-Gm-Message-State: AKaTC03IDO1u4MdlofQO577dH+cWA7XKShE2t+SPINbjRDAhr8J/uucFJ6n/7q4cxCYLAPgQae2B+kggZva3ZA== X-Received: by 10.200.44.27 with SMTP id d27mr5536617qta.278.1479942606758; Wed, 23 Nov 2016 15:10:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Wed, 23 Nov 2016 15:10:06 -0800 (PST) In-Reply-To: References: <4e2b054a-c391-d4f9-c106-d62eb90e2034@akamai.com> From: Martin Thomson Date: Thu, 24 Nov 2016 10:10:06 +1100 Message-ID: To: Victor Vasiliev Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] SNI and Resumption/0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 23 Nov 2016 23:10:09 -0000 On 24 November 2016 at 09:46, Victor Vasiliev wrote: > For concreteness, I wrote a pull request that describes (2): > At this point, I think that it would be more sensible to write a separate extension draft. There are a bunch of additional considerations that would be easier to write down in a dedicated document. From nobody Wed Nov 23 18:18:57 2016 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 75C7F129651 for ; Wed, 23 Nov 2016 18:18:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 LSRE8kzjQMjL for ; Wed, 23 Nov 2016 18:18:50 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (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 5F86C129663 for ; Wed, 23 Nov 2016 18:18:50 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id t125so27669566ywc.1 for ; Wed, 23 Nov 2016 18:18:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BVksZDZhk0vRhfLO60WRBYZw+Lh9PRGe5ybRhkEKx+Y=; b=SXxQxTnhe4NAnOAhFSljBE9bOX2ZC8MIUTcJBQDGm7Jv4VtE9j4bZPIx6NPc3ULIfy U4k0ZD+7DwrF253gKRl3W+/70Q4rOj30sBy/W4E3Rs8sHOK5Zm2kTBx0p4wGgwu1CUv4 9l8CDsUimWoa91+oeBvHdsYKxgnZ+vbN82aYGsNx3FBNdFzkc4SGidE9duzwCx2MnDrX RHqY8kBtvmwznqZ64YZlfIRJxXRlZaYnhBja8hiH7UQnpzrxg0Cdhbbvo0UsZnqtYQfG 7q+fZC+BQ9sKy3qbMTs3GmyWobvJIp9ouKhZOkBGbDrWURRhP6tmdBG7Dn2YhQPqSq6k n7XA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BVksZDZhk0vRhfLO60WRBYZw+Lh9PRGe5ybRhkEKx+Y=; b=dvkz4e8yN5Fd3V6aZFE1MkO8t40OPo02Ki9o175hFvZEbG213tnoyPC5HLrMS2cG8O aBNcD8XdEW49xRToFVjBWeuGBpvK5cgDnhy1epP3RqBNeTPMi5Dy3IhfuAksqB9gHbCN xE7bmdeUd8/ETwOxaxaMIU8AcQEVaHgLiwEAxtQkzWn1f82CQhki41rIkE9r6A/00Jm7 bQ3fi+vGzMZNv+eeI1avPsnlUwKCPxGoymVXXgWDB79xL1uMakiqsbgf2JOWE1Z7mrDx 0FS2Vsh2IuGO9uT9muypdRtr+z0OjxUT2eAiCCJ+AqpWqBOtMYRAVeVU/NpK8bpBAEJ1 xT3Q== X-Gm-Message-State: AKaTC01WKmNQMqg0dvrrEtPXmvVImyfBoUHKZPxvinK1A/EKnCv+yfyHnGbv8DY+/aeMcnF8lYg97PVUydXQ+g== X-Received: by 10.13.217.9 with SMTP id b9mr61279ywe.44.1479953929511; Wed, 23 Nov 2016 18:18:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.115.3 with HTTP; Wed, 23 Nov 2016 18:18:49 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 23 Nov 2016 18:18:49 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114fac3240d2a1054202a064 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Additional warnings on 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 02:18:54 -0000 --001a114fac3240d2a1054202a064 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 23, 2016 at 3:03 PM, Martin Thomson wrote: > This seems like too much text to me. Maybe some people would > appreciate the reminder that replay might cause side-effects to be > triggered multiple times, or that side effects are just effects and > those might also be observable. But I think that those reminders > could be provided far more succinctly. > My main goal is clarity, especially to application builders. In my experience the implications of replay-ability are frequently overlooked and it's well worth being abundantly clear. For most builders, those full implications have never occurred to them (why would they?), so it's often not a reminder, but new knowledge. It warrants a big warning label, not FUD, but honestly scary because it is a very hard problem. But still, the text can most likely be shortened some, edits welcome. > The bit that concerns me most is the recommendation to intentionally > replay early data. Given that I expect that a deployment that enables > 0-RTT will tolerate some amount of side-effects globally, and that > excessive 0-RTT will trigger DoS measures, all you are doing is > removing some of the safety margin those services operate with Can I break this into two parts then? First, do you agree that it would be legitimate for a client, or an implementation (library), to deliberately replay 0-RTT data? E.g. browsers and TLS libraries MAY implement this as a safety mechanism, to enforce and audit the server's and application's ability to handle the challenges of replay-ability correctly. At a bare minimum I want to be free to include this in our implementation of TLS, and in the clients that we use. I think there's value in explicitly documenting this, and that the problem is squarely on the server side if it is not replay-even-within-time-window-tolerant. Frankly: I want to be able to point to the spec and it be clear whose fault it is. Now second, consider a web service API that exists today and is using TLS. Many such APIs depend entirely on TLS for all anti-replay protection (though for the record, the SigV4 authentication mechanism we use at AWS includes its own anti-replay measure). When TLS1.3 comes along it is *very* tempting for providers to turn it on and use it for those APIs. Everyone always wants everything to be faster, and it won't be a huge code change. The problems of replay attacks could be dismissed as unlikely and left unaddressed, as security issues often are. So through a very predictable set of circumstances, I think those calls will be left vulnerable to replay issues and TLS1.3 will absolutely degrade security in these cases. What I'm suggesting is that we RECOMMEND a systematic defense: clients and/or implementations should intentionally generate duplicate data, so that the problem *has* to be addressed at least in some measure by providers. I far prefer that they be forced to encounter a low grade of errors early in their testing than to leave a large hole looming for users to fall into. This style of "Always always test the attack case in production" is also just a good practice that keeps anti-bodies strong. Thanks for reading and the feedback. On 24 November 2016 at 04:47, Colm MacC=C3=A1rthaigh wr= ote: > > > > I've submitted a PR with an expanded warning on the dangers of 0-RTT da= ta > > for implementors: > > > > https://github.com/tlswg/tls13-spec/pull/776/files > > > > The text is there, and the TLDR summary is basically that time-based > > defenses aren't sufficient to mitigate idempotency bugs, so application= s > > need to be aware of the sharp edges and have a plan. For clarity, I've > > outlined three example security issues that could arise due to realisti= c > and > > straightforward, but naive, use of 0-RTT. There's been some light > discussion > > of each in person and on the list. > > > > In the PR I'm "MUST"ing that applications need to include /some/ > mitigation > > for issues of this class (or else they are obviously insecure). In my > > experience this class of issue is so pernicious, and easy to overlook, > that > > I'm also "RECOMMEND"ing that applications using Zero-RTT data > > *intentionally* replay 0-RTT data non-deterministically, so as to keep > > themselves honest. > > > > At a bare minimum I think it would be good to make clear that clients a= nd > > implementations MAY intentionally replay 0-RTT data; to keep servers on > > their toes. For example a browser could infrequently tack on a dummy > > connection with repeated 0-RTT data, or an implementation could > periodically > > spoof a 0-RTT section to the application. That should never be > considered a > > bug. but a feature. (And to be clear: I want to do this in our > > implementation). > > > > > > -- > > Colm > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > --=20 Colm --001a114fac3240d2a1054202a064 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On W= ed, Nov 23, 2016 at 3:03 PM, Martin Thomson <martin.thomson@gmail= .com> wrote:
This seems like too much text to me.=C2=A0 Maybe some people would
appreciate the reminder that replay might cause side-effects to be
triggered multiple times, or that side effects are just effects and
those might also be observable.=C2=A0 But I think that those reminders
could be provided far more succinctly.

= My main goal is clarity, especially to application builders. In my experien= ce the implications of replay-ability are frequently overlooked and it'= s well worth being abundantly clear.=C2=A0 For most builders, those full im= plications have never occurred to them (why would they?), so it's often= not a reminder, but new knowledge. It warrants a big warning label, not FU= D, but honestly scary because it is a very hard problem.=C2=A0
But still, the text can most likely be shortened some, edits w= elcome.=C2=A0


The bit that concerns me most is the recommendation to intentionally
replay early data.=C2=A0 Given that I expect that a deployment that enables=
0-RTT will tolerate some amount of side-effects globally, and that
excessive 0-RTT will trigger DoS measures, all you are doing is
removing some of the safety margin those services operate with=C2=A0

Can I break this into two parts then? First, do y= ou agree that it would be legitimate for a client, or an implementation (li= brary), to deliberately replay 0-RTT data? E.g. browsers and TLS libraries = MAY implement this as a safety mechanism, to enforce and audit the server&#= 39;s and application's ability to handle the challenges of replay-abili= ty correctly. =C2=A0

At a bare minimum I want to b= e free to include this in our implementation of TLS, and in the clients tha= t we use. I think there's value in explicitly documenting this, and tha= t the problem is squarely on the server side if it is not replay-even-withi= n-time-window-tolerant. Frankly: I want to be able to point to the spec and= it be clear whose fault it is.=C2=A0

Now second, = consider a web service API that exists today and is using TLS. Many such AP= Is depend entirely on TLS for all anti-replay protection (though for the re= cord, the SigV4 authentication mechanism we use at AWS includes its own ant= i-replay measure). When TLS1.3 comes along it is *very* tempting for provid= ers to turn it on and use it for those APIs. Everyone always wants everythi= ng to be faster, and it won't be a huge code change. The problems of re= play attacks could be dismissed as unlikely and left unaddressed, as securi= ty issues often are.=C2=A0

So through a very predi= ctable set of circumstances, I think those calls will be left vulnerable to= replay issues and TLS1.3 will absolutely degrade security in these cases. = What I'm suggesting is that we RECOMMEND a systematic defense: clients = and/or implementations should intentionally generate duplicate data, so tha= t the problem *has* to be addressed at least in some measure by providers. = I far prefer that they be forced to encounter a low grade of errors early i= n their testing than to leave a large hole looming for users to fall into.<= /div>

This style of "Always always test the attack = case in production" is also just a good practice that keeps anti-bodie= s strong.=C2=A0

Thanks for reading and the feedbac= k.


On 24 November 2016 at 04:47, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
>
> I've submitted a PR with an expanded warning on the dangers of 0-R= TT data
> for implementors:
>
> https://github.com/tlswg/tls13-spec/pull= /776/files
>
> The text is there, and the TLDR summary is basically that time-based > defenses aren't sufficient to mitigate idempotency bugs, so applic= ations
> need to be aware of the sharp edges and have a plan.=C2=A0 For clarity= , I've
> outlined three example security issues that could arise due to realist= ic and
> straightforward, but naive, use of 0-RTT. There's been some light = discussion
> of each in person and on the list.
>
> In the PR I'm "MUST"ing that applications need to includ= e /some/ mitigation
> for issues of this class (or else they are obviously insecure). In my<= br> > experience this class of issue is so pernicious, and easy to overlook,= that
> I'm also "RECOMMEND"ing that applications using Zero-RTT= data
> *intentionally* replay 0-RTT data non-deterministically, so as to keep=
> themselves honest.
>
> At a bare minimum I think it would be good to make clear that clients = and
> implementations MAY intentionally replay 0-RTT data; to keep servers o= n
> their toes. For example a browser could infrequently tack on a dummy > connection with repeated 0-RTT data, or an implementation could period= ically
> spoof a 0-RTT section to the application. That should never be conside= red a
> bug. but a feature. (And to be clear: I want to do this in our
> implementation).
>
>
> --
> Colm
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



--
Colm
--001a114fac3240d2a1054202a064-- From nobody Wed Nov 23 19:31:30 2016 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 714AD12940C for ; Wed, 23 Nov 2016 19:31:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id soYsY7JqjM1P for ; Wed, 23 Nov 2016 19:31:27 -0800 (PST) Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 4CCF3129406 for ; Wed, 23 Nov 2016 19:31:27 -0800 (PST) Received: by mail-qk0-x22b.google.com with SMTP id n204so37023397qke.2 for ; Wed, 23 Nov 2016 19:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=6/mOvaPwMdMnJPlH1B7ixKI6AxG49QiZ93EkBrcnBQ4=; b=nwbdV6p1aTEzUU0OPUsjznL3Beyo8hlnonQSqHVkJBjROWmSxXxIn2uqMtNqscum7y LzUA6kNqAm2h7Q8CXpXL1xb82hKfL6qBOhvDb/fOeZkJlnWbN4XS1lqWpNgEskxseNue YXvTNruLRV9y21nkfnkZ8pAcbN2zOU1kXgBkdQvewAS5A6bwKinKI//2u3IXrHRS9PU5 Lu8rQ+O37RpXhl0L+HzHZrjCnrFvfFZJA/M9ONoE/T/DFz2hKmBz65vuoWMD2JagSCXS DL57U/rIeA6A7F3XkchdJQnbazWePSHF4qVC3sxhT5ddiiJH+6Kx86YVDtFq+9fhN25b U+Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=6/mOvaPwMdMnJPlH1B7ixKI6AxG49QiZ93EkBrcnBQ4=; b=SkJjQD1adaJdeKAwzhovO3cG6xFQRXhG/pv952PSbotZGRqppp6YFHbRf+JYdSfK2t T+e0+Flzr84nBFGQRP8SpV0xrTdEtxnA9xWMGBRncydL89o2V8lbCmUKkUfER+bHezDb RnZw90zbertgHDSTRRG6dN9z88LHCq8thyYZTSIAee1aRl/eudqb4yHhEPZ3mr/aETIy PNco1bIRvBf4Pv//ZZm0LMBvJIK/MiLwAk8+6vkhfVe8AiftQ1Nbun1JNHYm9wsLoEqm dq3PU8pUDdNjwW/jlnq3MnQ7+l1cxTOCsu0V761xTaAq/WnAURTiMvKts/WZesjrqdBT IDLw== X-Gm-Message-State: AKaTC01B3paeB4H6ghWQE0iV0CV5/ZmlVEOpNYNzwTsudh0od5Dzbjj7D/wP2WiPzlvMTsmrIAqXFcQjYyRzJQ== X-Received: by 10.233.235.72 with SMTP id b69mr192751qkg.144.1479958286471; Wed, 23 Nov 2016 19:31:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Wed, 23 Nov 2016 19:31:25 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 24 Nov 2016 14:31:25 +1100 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Additional warnings on 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 03:31:28 -0000 On 24 November 2016 at 13:18, Colm MacC=C3=A1rthaigh wr= ote: > Can I break this into two parts then? First, do you agree that it would b= e > legitimate for a client, or an implementation (library), to deliberately > replay 0-RTT data? E.g. browsers and TLS libraries MAY implement this as = a > safety mechanism, to enforce and audit the server's and application's > ability to handle the challenges of replay-ability correctly. OK, let's be clear: I don't agree that the level of paranoia surrounding 0-RTT is warranted. I'm of the belief that end-to-end replay is a property we should be building in to protocols, not just something a transport layer does for you. On the web, that's what happens, and it contributes greatly to overall reliability. The reaction to perceived problems in 0-RTT is disproportionate. You are asking for a license to replay here at some arbitrary layer of the stack. That's not principled, it's just on the basis that you don't like 0-RTT and want to innoculate other people's software against the ill effects it might create. What I object to here is the externalizing that this represents. Now if I have the audacity to deploy 0-RTT, I have to tolerate some amount of extra trash traffic from legitimate clients? From nobody Wed Nov 23 20:12:04 2016 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 04B1B12943A for ; Wed, 23 Nov 2016 20:12:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 i3QWdAehtaxL for ; Wed, 23 Nov 2016 20:12:01 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 4FE37129413 for ; Wed, 23 Nov 2016 20:12:01 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id a10so29223040ywa.3 for ; Wed, 23 Nov 2016 20:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+6I4ISd4rD0rRrcjGtm4PyxkO8FO0Kqkku/17RoQ8HA=; b=X9uXJsFKz1qEVCCEk7GW4ewbG2/wbDgq1uTU2nqB1OvV+Rm2iLKxKgc+fvOBdbKwhV aVE/sBG3C/wbQ2AWBRI8mHaFuFnqZmFw3o5r8kburdLRjf5CyhdLJb84NRYaaLmjxyg0 Mw+OofUsiRT9ElQEMEm8bjOU6QbH+u1XVJASaH6OpuKchWX08eswhO9eQPI7+h/jl0ge /dq6XfI1g191O3eM5bA8PAxF9RRZsysfhbO4OJM44zyQInn5sRVV2PAaGgbln9xV4IDA r/+uHJTJCrvTS0sU9Sy8fEk5TnXsckTQR/Qstcahv41bUUKo+CSh3/N/hwl0fdxJ+ej1 LsjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+6I4ISd4rD0rRrcjGtm4PyxkO8FO0Kqkku/17RoQ8HA=; b=MTBZ4QTtoRf14Qil/ImhZGlzoSHRab9UrvErmuv0zzgr/RoklsYKDbLBuF5LVb3hZi wYtybVoqvnYXr4qKjFNfiV9TAxPSelbW1qIySHs80PUTHvcdNUdscR3hLQKPxE5Ap2C0 rLowujoTtwFSLSfoIg0XGfKFzw5qZooJpQwWGijxszUh80vYRBBtqnzc0MmN64aFDHgu LT3x7yAGLvKtGidJ2Hp6iA4NDuAlwaMzj01gjd6LJnFMx+v62kAP4qpUJLIofcVjXTZE Ym9LucEHpb3uJRdelTO5qlBGJgVist8MHkHYCoYH0XR+FA4dpbh5t+xCxT+kJjHugih/ 1qMQ== X-Gm-Message-State: AKaTC02JUYwwTrpME8M6DbdJJg7pmlfwaEtu7njykgQA52wbEBWqN8ix5A9ZQubHUcrBykG3PyvU3IYeFX1SbA== X-Received: by 10.13.199.193 with SMTP id j184mr439402ywd.339.1479960719979; Wed, 23 Nov 2016 20:11:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.115.3 with HTTP; Wed, 23 Nov 2016 20:11:59 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 23 Nov 2016 20:11:59 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a114e544aff267a05420434b6 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Additional warnings on 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 04:12:03 -0000 --001a114e544aff267a05420434b6 Content-Type: text/plain; charset=UTF-8 On Wed, Nov 23, 2016 at 7:31 PM, Martin Thomson wrote: > OK, let's be clear: I don't agree that the level of paranoia > surrounding 0-RTT is warranted. Do you disagree that the three specific example security issues provided are realistic, representative and impactful? If so, what would persuade you to change your mind? > I'm of the belief that end-to-end > replay is a property we should be building in to protocols, not just > something a transport layer does for you. On the web, that's what > happens, and it contributes greatly to overall reliability. > The proposal here I think promotes that view; if anything, it nudges protocols/applications to actually support end-to-end replay. > The reaction to perceived problems in 0-RTT is disproportionate. You are asking for a license to replay here at some arbitrary layer of the > stack. That's not principled, it's just on the basis that you don't > like 0-RTT and want to innoculate other people's software against the > ill effects it might create. The problems of 0-RTT are disproportionately under-estimated. I've provided what I think are three concrete and realistic security issues. If we disagree on those, let's draw that out, because my motivation is to mitigate those new issues that are introduced by TLS1.3. > What I object to here is the externalizing that this represents. Now if I > have the audacity to > deploy 0-RTT, I have to tolerate some amount of extra trash traffic > from legitimate clients? > I think there is a far worse externalization if we don't do this. Consider the operations who choose not (or don't know) to add good replay protection. They will iterate more quickly and more cheaply than the diligent providers who are cautious to add the effective measures, which are expensive and difficult to get right. That is a perverse incentive, and ultimately users would pay the price. I have the same gut reaction against sending duplicate data and having a sort of "tax on everyone" for the sake of safety as you, it's icky, but I haven't been able to think of another mitigation for the problems that would be as effective. -- Colm --001a114e544aff267a05420434b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 23, 2016 at 7:31 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
OK, let's be clear= : I don't agree that the level of paranoia
surrounding 0-RTT is warranted.=C2=A0

Do y= ou disagree that the three specific example security issues provided are re= alistic, representative and impactful? If so, what would persuade you to ch= ange your mind?
=C2=A0
I'm of the belie= f that end-to-end
replay is a property we should be building in to protocols, not just
something a transport layer does for you.=C2=A0 On the web, that's what=
happens, and it contributes greatly to overall reliability.

The proposal here I think promotes that view; if anyth= ing, it nudges protocols/applications to actually support end-to-end replay= .=C2=A0
=C2=A0
The reaction to perceived problems in 0-RTT is disproportionate. You
are asking for a license to replay here at some arbitrary layer of the
stack.=C2=A0 That's not principled, it's just on the basis that you= don't
like 0-RTT and want to innoculate other people's software against the ill effects it might create.=C2=A0

The prob= lems of 0-RTT are disproportionately under-estimated. I've provided wha= t I think are three concrete and realistic security issues. If we disagree = on those, let's draw that out, because my motivation is to mitigate tho= se new issues that are introduced by TLS1.3.=C2=A0
=C2=A0
What I object to here is the=C2=A0externalizing that this re= presents.=C2=A0 Now if I have the audacity to
deploy 0-RTT, I have to tolerate some amount of extra trash traffic
from legitimate clients?

I think there = is a far worse externalization if we don't do this. Consider the operat= ions who choose not (or don't know) to add good replay protection. They= will iterate more quickly and more cheaply than the diligent providers who= are cautious to add the effective measures, which are expensive and diffic= ult to get right. That is a perverse incentive, and ultimately users would = pay the price.

I have the same gut reaction agains= t sending duplicate data and having a sort of "tax on everyone" f= or the sake of safety as you, it's icky, but I haven't been able to= think of another mitigation for the problems that would be as effective.= =C2=A0

--
Colm=
--001a114e544aff267a05420434b6-- From nobody Wed Nov 23 20:40:29 2016 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 8FFCF12946C for ; Wed, 23 Nov 2016 20:40:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nz2qvtZ9sZ8m for ; Wed, 23 Nov 2016 20:40:27 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (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 C6323129427 for ; Wed, 23 Nov 2016 20:40:26 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id x190so38189632qkb.0 for ; Wed, 23 Nov 2016 20:40:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=xdTYNn3AsefF+LnbeEqy15koTsxQF2xTay71rU0IHN0=; b=h8mi+lX47tVta3FxSU3dWyYAR1ne2zDmRQwh6eCj/ZRvrPv2A0xOKN297jtzy6O4Sw e4L+T5+7NGAFCcstvy/85CWuC821VLLntW2ppM95wKCDSf2pWptZVUgEvANGhsyB+aRz b2DU8vNWwOVZDmGGlFISFE6JjR9JSPE0E0RhGKvsH8MoKJi8cVIxdHkR1OvIGmDyQ2WV nUdnyU/uX55gfd776Edf1owvcq3CbzwgRcxzydhoOqHfnc2i2epdWRxHIbGGlWgqbqHA L+ZYKNGagLN3He2oGTNNpKEIVjYm88f5geoaASm8q+brIFdprqevEtOkInYnxNnJAoiG DbnA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=xdTYNn3AsefF+LnbeEqy15koTsxQF2xTay71rU0IHN0=; b=ZWNw3Kqn20urNNbh2+wRs3HoXPItgWdIsd0rA0i3IgnF32gakDIug7zTpNr++PVXqu +b+4jO3G47mAvF4Ya41KZbI6Jv8C/X9sWs5ZwFjBcCanMSTi1PLUa8y+b1D808E2PRgl qSbSMQZ08ZhKVZ/vDso6DI8WI/1Yjy8tc4K2v8XMJBpFJHd2eyOzhtTAVzazPzX9x6ZL YFKWDj4rSHzhMmWHQlQqyLOmiSGEtT9zk9DXc9D1HBlS5CTgfco8rM5kwSWPWqLSiZ58 ZgOws5Or+NH5XaEVqtZwdsOGfAuSsHQZOkkKM8yJ0gpNBtoztz29j0/USvJmvwhBZ8Mc Fulg== X-Gm-Message-State: AKaTC019KJ0V9HBogI94uFXlcQjBqC9jZlVKhypXNgHT5k4Q9ZxTFQyaW1K3SH/B0/85+1zOrEsOyRGwfHV4eg== X-Received: by 10.233.235.72 with SMTP id b69mr346730qkg.144.1479962425867; Wed, 23 Nov 2016 20:40:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.85.101 with HTTP; Wed, 23 Nov 2016 20:40:25 -0800 (PST) In-Reply-To: References: From: Martin Thomson Date: Thu, 24 Nov 2016 15:40:25 +1100 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Additional warnings on 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 04:40:28 -0000 On 24 November 2016 at 15:11, Colm MacC=C3=A1rthaigh wr= ote: > Do you disagree that the three specific example security issues provided = are > realistic, representative and impactful? If so, what would persuade you t= o > change your mind? These are simply variants on "if someone hits you with a stick, they might hurt you", all flow fairly logically from the premise, namely that replay is possible (i.e., someone can hit you with a stick). The third is interesting, but it's also the most far-fetched of the lot (a server might read some bytes, which it later won't read, exposing a timing attack). But that's also corollary material; albeit less obvious. Like I said, I've no objection to expanding a little bit on what is possible: all non-idempotent activity, which might be logging, load, and some things that are potentially observable on subsequent requests, like IO/CPU cache state that might be affected by a request. >> I'm of the belief that end-to-end >> replay is a property we should be building in to protocols, not just >> something a transport layer does for you. On the web, that's what >> happens, and it contributes greatly to overall reliability. > > The proposal here I think promotes that view; if anything, it nudges > protocols/applications to actually support end-to-end replay. You are encouraging the TLS stack to do this, if not the immediate thing that drives it (in our case, that would be the HTTP stack). If the point is to make a statement about the importance of the end-to-end principle with respect to application reliability, the TLS spec isn't where I'd go for that. > The problems of 0-RTT are disproportionately under-estimated. I've provid= ed > what I think are three concrete and realistic security issues. If we > disagree on those, let's draw that out, because my motivation is to mitig= ate > those new issues that are introduced by TLS1.3. > >> What I object to here is the externalizing that this represents. Now if= I >> have the audacity to >> deploy 0-RTT, I have to tolerate some amount of extra trash traffic >> from legitimate clients? > > > I think there is a far worse externalization if we don't do this. Conside= r > the operations who choose not (or don't know) to add good replay protecti= on. > They will iterate more quickly and more cheaply than the diligent provide= rs > who are cautious to add the effective measures, which are expensive and > difficult to get right. OK let's ask a different question: who is going to do this? It's a non-trivial thing you ask for. This involves a new connection setup just to send a few packets, and probably a timer so that you can wait long enough for the server to explode. Do you expect to replay before the real attempt? Because that's even less likely to happen. Connections aren't cheap, bandwidth as well. And the time requirement for building such a feature would be better spent elsewhere, not to mention the ongoing maintenance. I don't see browsers doing anything like what you request; nor do I see tools/libs like curl or wget doing it either. If I'm wrong and they do, they believe in predictability so won't add line noise without an application asking for it. If few enough people do this, what makes you think that such a tiny amount of replay would make any difference? Unless you replay with high probability, then the odd error will be dismissed as a transient. This is especially true because most of these sorts of exploitable errors will happen adjacent to some sort of network glitch (the requests at the start of most connections - on the web at least - are pretty lame). Then you all you have done is increased the global rate of "have you turned it off and on again?", which is - after all - yet another opportunity for replay. From nobody Wed Nov 23 21:20:01 2016 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 ABA411294D1 for ; Wed, 23 Nov 2016 21:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 GPV9ZrsB22YK for ; Wed, 23 Nov 2016 21:19:57 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 8F5DC129484 for ; Wed, 23 Nov 2016 21:19:57 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id c21so57374322ioj.1 for ; Wed, 23 Nov 2016 21:19:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TkSI+dIskfMyPliIRRho5Gh8B6ISR4G2sBok+boaF6A=; b=kiM0WkTpdF8OIzXOLtUaP0JmlPCtSv2HEIravbinrtpJg3YvHuT7AfohkOtlzBYAze nyUyoKTdaxW3m61CtsFGBVgngCdaWDXCbcNQNR5L3L5DwC5L7Oa3Cr1jcWvubcsBxsB2 SvEYhPSm3jy803Kxb+3YKBzDTWJ8hS9hJXChVBuTXdSmu9MveYLQi2rVj2coZO/uVSxJ 8urPNw7Ob7y11TkUWmYUbQnxWV0+w/6TFkQD82jFYzoXy6r55uz8ccapYJNZHjsnm3NH vNZS0ZcM0Iodul0EMYVQMUDLimWdhB7Kw7tqM+DHjG4uuNPtEwSb4IQMfkglc/DOazYq 8i+A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TkSI+dIskfMyPliIRRho5Gh8B6ISR4G2sBok+boaF6A=; b=Z8id8DqIitkF6F8XSUqzc7kOtdTc8DJ+Fn0Mk8xUSx3yCENaj2clIgZBaUELl7xOih HrudG9n1+KPnqDB8OXaJQ0z2miMCvvDvHsCKUSiiYJwXmWS1N4e+5g4WH/CEClQJTwMO whgD4xuQtYGK56rEYrGgvk4NCSnKemwOvJSfVb/41e6wEKA65uPYPWNQhCG/67Uo9vbz a1PBqe51h/uzurxm19pV7A+jO2ImJuNb7gMltgg9mL6PT2uhZWP3BttXhQcbCXjDHPuF BWYITVpfIDZqTNNdQVoupe5zr4xfA3ZJi2MegjdNOcT5nKI0a30NTNK0/ws4aR9dFT7N ySlA== X-Gm-Message-State: AKaTC00rrAipI6NxpOyZsCJrGK5HKIceYEcMEvPWHPJiZckNOS2AeMNI6SdFKun/Cl/oi3hVPGgRRd+baT2kTQ== X-Received: by 10.107.170.230 with SMTP id g99mr449994ioj.111.1479964796867; Wed, 23 Nov 2016 21:19:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.36.224.74 with HTTP; Wed, 23 Nov 2016 21:19:56 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 23 Nov 2016 21:19:56 -0800 Message-ID: To: Martin Thomson Content-Type: multipart/alternative; boundary=001a1142e6b0ff71c605420527a2 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Additional warnings on 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 05:20:00 -0000 --001a1142e6b0ff71c605420527a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 23, 2016 at 8:40 PM, Martin Thomson wrote: > On 24 November 2016 at 15:11, Colm MacC=C3=A1rthaigh = wrote: > > Do you disagree that the three specific example security issues provide= d > are > > realistic, representative and impactful? If so, what would persuade you > to > > change your mind? > > These are simply variants on "if someone hits you with a stick, they > might hurt you", all flow fairly logically from the premise, namely > that replay is possible (i.e., someone can hit you with a stick). > Prior to TLS1.3, replay is not possible, so the risks are new, but the end-to-end designers may not realize to update their threat model and just what is required. I'd like to spell that out more than what's where at present. The third is interesting, but it's also the most far-fetched of the > lot (a server might read some bytes, which it later won't read, > exposing a timing attack). I need to work on the wording because the nature of the attack must not be clear. It's really simple. If the 0-RTT data primes the cache, then a subsequent request will be fast. If not, it will be slow. If implemented on a CDN for example, the effort required would be nearly trivial for an attacker. Basically: I replay the 0-RTT data, then probe a bunch of candidate resources with regular requests. If one of them loads in 20ms and the others load in 100ms, well now I know which resource the 0-RTT data was for. I can perform this attack against CDN nodes that are quiet, or remote, and very unlikely to have the resources cached to begin with. > But that's also corollary material; albeit > less obvious. Like I said, I've no objection to expanding a little > bit on what is possible: all non-idempotent activity, which might be > logging, load, and some things that are potentially observable on > subsequent requests, like IO/CPU cache state that might be affected by > a request. > ok, cool :) > >> I'm of the belief that end-to-end > >> replay is a property we should be building in to protocols, not just > >> something a transport layer does for you. On the web, that's what > >> happens, and it contributes greatly to overall reliability. > > > > The proposal here I think promotes that view; if anything, it nudges > > protocols/applications to actually support end-to-end replay. > > You are encouraging the TLS stack to do this, if not the immediate > thing that drives it (in our case, that would be the HTTP stack). If > the point is to make a statement about the importance of the > end-to-end principle with respect to application reliability, the TLS > spec isn't where I'd go for that. > I'm not sure where the folks designing the HTTP and other protocols would get the information from if not the TLS spec. It is TLS that's changing too. Hardly any harm in duplicating the advice anyway. > > I think there is a far worse externalization if we don't do this. > Consider > > the operations who choose not (or don't know) to add good replay > protection. > > They will iterate more quickly and more cheaply than the diligent > providers > > who are cautious to add the effective measures, which are expensive and > > difficult to get right. > > OK let's ask a different question: who is going to do this? > I am, for one. I don't see 0-RTT as a "cheap" feature. It's a very very expensive one. To mitigate the kind of issues it brings really requires atomic transactions. Either the application needs them, or something below it does. So far I see fundamentally no "out" of that, and once we have atomic transactions then we either have some kind of multi-phase commit protocol, distributed consensus, routing of data to master nodes, or some combination thereof. The smartest people I've ever met work on these kinds of systems and they all say it's really really hard and subtle. So when I imagine Zero-RTT being done correctly, I imagine organizations signing up for all of that, and it being worth it, because latency matters that much. That's a totally valid decision. And in that context, the additional expense of intentionally replaying 0-RTT seems minor and modest. My own tentative plan is to do it at the implementation level; to have the TLS library occasionally spoof 0-RTT data sections towards the application. This is the same technique used for validating non-replayable request-level auth. I don't see browsers doing anything like what you request; nor do I > see tools/libs like curl or wget doing it either. If I'm wrong and > they do, they believe in predictability so won't add line noise > without an application asking for it. > I hope this isn't the case, but if it is and browsers generally agree that it would be unimplementable and impractical, then I think 0-RTT should be removed unless we can come up with other effective mitigations. Otherwise it's predictable that we'll see deployments that don't bother to solve the hard problems and are vulnerable to the issues I've described. But let's not be doom and gloom about it, there's got to be a way to mitigate. --=20 Colm --001a1142e6b0ff71c605420527a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 23, 2016 at 8:40 PM, Martin Thomson <<= a href=3D"mailto:martin.thomson@gmail.com" target=3D"_blank">martin.thomson= @gmail.com> wrote:
On 24 November 2016 at 15:11, Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
> Do you disagree that the three specific example security issues provid= ed are
> realistic, representative and impactful? If so, what would persuade yo= u to
> change your mind?

These are simply variants on "if someone hits you with a stick,= they
might hurt you", all flow fairly logically from the premise, namely that replay is possible (i.e., someone can hit you with a stick).

Prior to TLS1.3, replay is not possible, so the = risks are new, but the end-to-end designers may not realize to update their= threat model and just what is required. I'd like to spell that out mor= e than what's where at present.=C2=A0

The third is interesting, but it's also the most far-fetched of the
lot (a server might read some bytes, which it later won't read,
exposing a timing attack).=C2=A0

I need to= work on the wording because the nature of the attack must not be clear. It= 's really simple. If the 0-RTT data primes the cache, then a subsequent= request will be fast. If not, it will be slow.=C2=A0

<= div>If implemented on a CDN for example, the effort required would be nearl= y trivial for an attacker. Basically: I replay the 0-RTT data, then probe a= bunch of candidate resources with regular requests. If one of them loads i= n 20ms and the others load in 100ms, well now I know which resource the 0-R= TT data was for. I can perform this attack against CDN nodes that are quiet= , or remote, and very unlikely to have the resources cached to begin with.= =C2=A0
=C2=A0
But that's = also corollary material; albeit
less obvious.=C2=A0 Like I said, I've no objection to expanding a littl= e
bit on what is possible: all non-idempotent activity, which might be
logging, load, and some things that are potentially observable on
subsequent requests, like IO/CPU cache state that might be affected by
a request.

ok, cool :)
=C2=A0=
>> I'm of the belief that end-to-end
>> replay is a property we should be building in to protocols, not ju= st
>> something a transport layer does for you.=C2=A0 On the web, that&#= 39;s what
>> happens, and it contributes greatly to overall reliability.
>
> The proposal here I think promotes that view; if anything, it nudges > protocols/applications to actually support end-to-end replay.

You are encouraging the TLS stack to do this, if not the immediate thing that drives it (in our case, that would be the HTTP stack).=C2=A0 If<= br> the point is to make a statement about the importance of the
end-to-end principle with respect to application reliability, the TLS
spec isn't where I'd go for that.

I'm not sure where the folks designing the HTTP and other protocols = would get the information from if not the TLS spec. It is TLS that's ch= anging too. Hardly any harm in duplicating the advice anyway.=C2=A0
=C2=A0
> I think there is a far worse externalization if we don't do this. = Consider
> the operations who choose not (or don't know) to add good replay p= rotection.
> They will iterate more quickly and more cheaply than the diligent prov= iders
> who are cautious to add the effective measures, which are expensive an= d
> difficult to get right.

OK let's ask a different question: who is going to do this?
<= /blockquote>

I am, for one. I don't see 0-RTT as a &= quot;cheap" feature. It's a very very expensive one. To mitigate t= he kind of issues it brings really requires atomic transactions. Either the= application needs them, or something below it does. So far I see fundament= ally no "out" of that, and once we have atomic transactions then = we either have some kind of multi-phase commit protocol, distributed consen= sus, routing of data to master nodes, or some combination thereof.=C2=A0

The smartest people I've ever met work on these = kinds of systems and they all say it's really really hard and subtle. S= o when I imagine Zero-RTT being done correctly, I imagine organizations sig= ning up for all of that, and it being worth it, because latency matters tha= t much. That's a totally valid decision.=C2=A0

And in that context, the additional expense of intentionally replaying 0-R= TT seems minor and modest. My own tentative plan is to do it at the impleme= ntation level; to have the TLS library occasionally spoof 0-RTT data sectio= ns towards the application. This is the same technique used for validating = non-replayable request-level auth.=C2=A0

I don't see browsers doing anything like what you requ= est; nor do I
see tools/libs like curl or wget doing it either.=C2=A0 If I'm wrong an= d
they do, they believe in predictability so won't add line noise
without an application asking for it.

I= hope this isn't the case, but if it is and browsers generally agree th= at it would be unimplementable and impractical, then I think 0-RTT should b= e removed unless we can come up with other effective mitigations. Otherwise= it's predictable that we'll see deployments that don't bother = to solve the hard problems and are vulnerable to the issues I've descri= bed. But let's not be doom and gloom about it, there's got to be a = way to mitigate.=C2=A0

--
Colm
--001a1142e6b0ff71c605420527a2-- From nobody Wed Nov 23 22:46:06 2016 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 EF88C1294B4 for ; Wed, 23 Nov 2016 22:46:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.703 X-Spam-Level: X-Spam-Status: No, score=-0.703 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 1_ri6XdfGLAc for ; Wed, 23 Nov 2016 22:46:03 -0800 (PST) Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 715A21294AE for ; Wed, 23 Nov 2016 22:46:03 -0800 (PST) Received: from xsmtp03.mail2web.com ([168.144.250.223]) by mx43.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1c9nnE-0003Xj-Qh for tls@ietf.org; Thu, 24 Nov 2016 07:46:01 +0100 Received: from [10.5.2.13] (helo=xmail03.myhosting.com) by xsmtp03.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1c9nmB-0005Wu-Bq for tls@ietf.org; Thu, 24 Nov 2016 01:45:58 -0500 Received: (qmail 16252 invoked from network); 24 Nov 2016 06:44:54 -0000 Received: from unknown (HELO icebox) (Authenticated-user:_huitema@huitema.net@[72.235.151.78]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 24 Nov 2016 06:44:54 -0000 From: "Christian Huitema" To: =?UTF-8?Q?'Colm_MacC=C3=A1rthaigh'?= , "'Martin Thomson'" References: In-Reply-To: Date: Wed, 23 Nov 2016 20:44:51 -1000 Message-ID: <095e01d2461e$4335acc0$c9a10640$@huitema.net> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQNc1L7s3QDNVvYw7W73bcafb42e8gF73kMlAVkLj7ACXw09ewJgQB2KAlNNRM4BpcQLy512J7QA Content-Language: en-us X-Filter-ID: s0sct1PQhAABKnZB5plbIVbU93hg6Kq00BjAzYBqWlUcW8ntawmIBRrYFzUH2lbvx1wTMkEUUoeb KIhkyzl2dP6iToxOOfkkkKBkEi+o3RqBn9PDoOhj/xzb7kHn/aQhIMekNi8AbP1K8LEdFLG4hgtb rTrWS9bemHrYlL1z57yRMRrvVMyrDQSCtfwipYMVGlugeeYNRP+TKatltgBEa/+k51CV8HOoCp+b WB2rXxPubplnbiDyBMUiEvUZuPnV9fApVgk0pB5h/LHiBh+ygEQqMGQOSwmEPwP4wBzM77OTVsmO 6uQQP+Ygzu7SVnOSquGQt1XNpx/AmufzrIpBz2hWDl86FRLsucalajANCROTEtSxjwHNYb/2LiS7 Aj0A9NgR8y+CBDNrETXWklX3dRIys/hHd7B5kQIJ1AmTVHYx2C8r0+n90PgZrVLZ+wLbZRWsGw8a c2InzcAP/gmxwP3syfTP+jLY1VVhnsOCDTCN/zt7adq46on0hk7vnxe46U0LjBzYuQztdAThgtWS U+4HJk0Zr//OJQKDI3aPfhBwB3GYi0UY+a4jCPcjJ1BDE9ykbJ7I9co1MAEE3ruNXvvg7iEFLP+S SY+Av5+AiC7JQKAKt33GE+tScjoV4oVfTWqb7+KkhmCiIKH9ch3Ck2CI2mWbDfKngUUUK5L6TqND iFwiZGp6gasQtfy6Uxde X-Report-Abuse-To: spam@quarantine5.antispamcloud.com X-Originating-IP: 168.144.250.223 X-SpamExperts-Domain: xsmtpout.mail2web.com X-SpamExperts-Username: 168.144.250.0/24 Authentication-Results: antispamcloud.com; auth=pass smtp.auth=168.144.250.0/24@xsmtpout.mail2web.com X-SpamExperts-Outgoing-Class: unsure X-SpamExperts-Outgoing-Evidence: Combined (0.22) X-Classification: unsure/combined X-Recommended-Action: accept Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Additional warnings on 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 06:46:05 -0000 On Wednesday, November 23, 2016 7:20 PM, Colm MacC=C3=A1rthaigh wrote: > > Prior to TLS1.3, replay is not possible, so the risks are new, but the = end-to-end designers > may not realize to update their threat model and just what is = required. I'd like to spell=20 > that out more than what's where at present.=20 Uh? Replay was always possible, at the application level. Someone might = for example click twice on the same URL, opening two tabs, closing one = at random. And that's without counting on deliberate mischief. -- Christian Huitema From nobody Wed Nov 23 23:38:42 2016 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 241CD129555 for ; Wed, 23 Nov 2016 23:38:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.496 X-Spam-Level: X-Spam-Status: No, score=-3.496 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hs-offenburg.de 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 4fWcGVsEF3o9 for ; Wed, 23 Nov 2016 23:38:39 -0800 (PST) Received: from mx.hs-offenburg.de (mx.hs-offenburg.de [141.79.11.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD58712954E for ; Wed, 23 Nov 2016 23:38:38 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.hs-offenburg.de (Postfix) with ESMTP id 396FC12F69E6 for ; Thu, 24 Nov 2016 08:38:36 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=hs-offenburg.de; h=content-type:content-type:mime-version:in-reply-to:references :subject:subject:from:from:date:date:x-mailer:message-id :received:received:received; s=default; t=1479973114; x= 1480837115; bh=pFugOYA21HXyLvEHQtNDHZn3lsYIDk9QUo5AHUPZOQg=; b=V NMTKzCeb7Hs1Y7RlPJBDj4ZMqCLifjO0328bo6yU9KH3WIG6TaLirmAyl73R4mB1 AVq//AXnuOyZEBLfOOFkyiHMzX6oF1Og7CQ8hDCFWleXnoPMy64u5h739jwWR/5d 6YF0snPUqfBsi39Vjt/MqrCzeAKNajRs1Y2na01Fj4= X-Virus-Scanned: amavisd-new at hs-offenburg.de Received: from mx.hs-offenburg.de ([127.0.0.1]) by localhost (mx.hs-offenburg.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCFDnra3G6qm for ; Thu, 24 Nov 2016 08:38:34 +0100 (CET) Received: from gwia2.rz.hs-offenburg.de (stud.hs-offenburg.de [141.79.10.30]) by mx.hs-offenburg.de (Postfix) with ESMTPS id 8DCD412F69D8 for ; Thu, 24 Nov 2016 08:38:34 +0100 (CET) Received: from gw_dom-gwia2-MTA by gwia2.rz.hs-offenburg.de with Novell_GroupWise; Thu, 24 Nov 2016 08:38:34 +0100 Message-Id: <5836A708020000AC001214A4@gwia2.rz.hs-offenburg.de> X-Mailer: Novell GroupWise Internet Agent 14.2.1 Date: Thu, 24 Nov 2016 08:38:32 +0100 From: "Andreas Walz" To: References: <47532130.8rB6yCJVvA@pintsize.usersys.redhat.com> <4268201.z3YH5P6ntS@pintsize.usersys.redhat.com> <79f10997-3bbc-fbce-91ae-2ceecaaa653e@akamai.com> <58358E07020000AC00121380@gwia2.rz.hs-offenburg.de> In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=__Part764F15E8.0__=" Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 07:38:41 -0000 This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=__Part764F15E8.0__= Content-Type: multipart/alternative; boundary="=__Part764F15E8.1__=" --=__Part764F15E8.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable >>> Eric Rescorla 11/23/16 2:18 PM >>> > In general, it should ignore it. It's going to become increasingly = common to=20 > have this be a version you don't support given the recommendation to use > 0301 and the ongoing deprecation of TLS 1.0. I think it would be fine to = sanity > check the major version, but I'm not sure what would be gained by = requiring this.=20 The one benefit of checking at least the record's major version I see is = that one preserves means for the future to signal a record format incompatible with = the current one. Otherwise, this field is given away for arbitrary and = non-standardized (ab)use ... =20 Thanks and Cheers, Andi ___________________________________ Andreas Walz Research Engineer Institute of reliable Embedded Systems and Communication Electronics = (ivESK) Offenburg University of Applied Sciences, 77652 Offenburg, Germany >>> Benjamin Kaduk 11/10/16 5:22 PM >>> On 11/08/2016 06:25 PM, Martin Thomson wrote: On 9 November 2016 at 05:59, Brian Smith = wrote: This isn't a pervasively shared goal, though. It's good to = let the browsers police things if they want, but I think a lot of implementations would prefer to avoid doing work that isn't necessary for interop or security. If you permit someone to enforce it, then that is sufficient.= I don't think that we should ever force someone to enforce these sorts of things (as you say, sometimes strict enforcement isn't cheap or even desirable). =20 Agreed. We should probably change the text a bit, though, as right = now readers can get two different readings depending on whether they = go for a strict decode_error (or illegal_parameter?) since the struct = doesn't match the definition, or follow the "MUST be ignored for all = purposes". =20 -Ben =20 =20 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 =20 --=__Part764F15E8.1__= Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Description: HTML =0Abody p =0A{ =0A margin: 0px; =0A}=0A
>>> Eric Rescorla&= nbsp;<ekr@rtfm.com> 11/23/16 2:18 PM >>>
> In = general, it should ignore it. It's going to become increasingly common to =
> have this be a version you don't support given the recommendation = to use
> 0301 and the ongoing deprecation of TLS 1.0. I think it = would be fine to sanity
> check the major version, but I'm not sure = what would be gained by requiring this. 

The one benefit of = checking at least the record's major version I see is that one
preserves= means for the future to signal a record format incompatible with = the
current one. Otherwise, this field is given away for arbitrary and = non-standardized
(ab)use ...

 

Thanks and Cheers,
Andi

_______________________________= ____

Andreas Walz
Research Engineer
Institute of reliable = Embedded Systems and Communication Electronics (ivESK)
Offenburg = University of Applied Sciences, 77652 Offenburg, Germany

 
>>> Benjamin Kaduk <bkaduk@akamai.com> 11/10/16 5:22 PM = >>>
 On 11/08/2016 06:25 PM, Martin Thomson = wrote:
On 9 November 2016 at 05:59, Brian =
Smith <brian@briansmith.org> =
wrote:
This isn't a pervasively =
shared goal, though. It's good to let the browsers
police things if =
they want, but I think a lot of implementations would
prefer to avoid =
doing work that isn't necessary for interop or security.
= 
If you permit someone to enforce it, then that is =
sufficient.  I don't
think that we should ever force someone to enforce =
these sorts of
things (as you say, sometimes strict enforcement isn't =
cheap or even
desirable).

= Agreed.  We should probably change the text a bit, though, as right = now readers can get two different readings depending on whether they = go for a strict decode_error (or illegal_parameter?) since the struct = doesn't match the definition, or follow the "MUST be ignored for all = purposes".

-Ben

_________________= ______________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


--=__Part764F15E8.1__=-- --=__Part764F15E8.0__=-- From nobody Thu Nov 24 05:03:20 2016 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 299371298D3; Thu, 24 Nov 2016 05:03:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.699 X-Spam-Level: X-Spam-Status: No, score=-105.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 LUHEIwEjlLhd; Thu, 24 Nov 2016 05:03:09 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADC38129953; Thu, 24 Nov 2016 05:03:09 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id AF3D3B8132E; Thu, 24 Nov 2016 05:03:08 -0800 (PST) To: azet@azet.org, jsalowey@cisco.com, abhijitc@cisco.com, mcgrew@cisco.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Message-Id: <20161124130308.AF3D3B8132E@rfc-editor.org> Date: Thu, 24 Nov 2016 05:03:08 -0800 (PST) Archived-At: Cc: tls@ietf.org, rfc-editor@rfc-editor.org, iesg@ietf.org Subject: [TLS] [Errata Verified] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 13:03:11 -0000 The following errata report has been verified for RFC5288, "AES Galois Counter Mode (GCM) Cipher Suites for TLS". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5288&eid=4694 -------------------------------------- Status: Verified Type: Technical Reported by: Aaron Zauner Date Reported: 2016-05-14 Verified by: Stephen Farrell (IESG) Section: 6.1 Original Text ------------- AES-GCM security requires that the counter is never reused. The IV construction in Section 3 is designed to prevent counter reuse. Implementers should also understand the practical considerations of IV handling outlined in Section 9 of [GCM]. Corrected Text -------------- Security of AES-GCM requires that the "nonce" (number used once) is never reused. The IV construction in Section 3 does not prevent implementers from reusing the nonce by mistake. It is paramount that the implementer be aware of the security implications when a nonce is reused even once. Nonce reuse in AES-GCM allows for the recovery of the authentication key resulting in complete failure of the mode's authenticity. Hence, TLS sessions can be effectively attacked through forgery by an adversary. This enables an attacker to inject data into the TLS allowing for XSS and other attack vectors. Notes ----- Obviously the original wording is so ambiguous that implementers got it wrong in the real world. Related to: https://www.blackhat.com/us-16/briefings.html#nonce-disrespecting-adversaries-practical-forgery-attacks-on-gcm-in-tls It may be worth adding a reference to [JOUX] http://csrc.nist.gov/groups/ST/toolkit/BCM/documents/...38.../GCM/Joux_comments.pdf and maybe the paper we're intending to release on the actual HTTPS forgery/injection attack. I'd actually like to change the nonce construction to that of the ChaCha20/Poly1305 document, but I figure this will cause massive breakage for already deployed implementations. TLS 1.3 fixes this issue per design. -------------------------------------- RFC5288 (draft-ietf-tls-rsa-aes-gcm-03) -------------------------------------- Title : AES Galois Counter Mode (GCM) Cipher Suites for TLS Publication Date : August 2008 Author(s) : J. Salowey, A. Choudhury, D. McGrew Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Nov 24 05:47:27 2016 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 403C81299B4 for ; Thu, 24 Nov 2016 05:47:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 oDfALhcV0Mc8 for ; Thu, 24 Nov 2016 05:47:25 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7AC31299A0 for ; Thu, 24 Nov 2016 05:47:24 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A41223D96E; Thu, 24 Nov 2016 13:47:24 +0000 (UTC) Received: from pintsize.usersys.redhat.com (ovpn-204-120.brq.redhat.com [10.40.204.120]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAODlNpo001088 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 24 Nov 2016 08:47:24 -0500 From: Hubert Kario To: tls@ietf.org Date: Thu, 24 Nov 2016 14:47:21 +0100 Message-ID: <2015444.TtsXi0aiky@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.8-200.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3858735.CsNdxGDNAf"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Thu, 24 Nov 2016 13:47:24 +0000 (UTC) Archived-At: Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 13:47:26 -0000 --nextPart3858735.CsNdxGDNAf Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 23 November 2016 10:50:37 CET Yoav Nir wrote: > On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos wrote: > > On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: > >> Hi, Nikos > >>=20 > >> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos > > That to my understanding is a way to reduce > > latency in contrast to cpu costs. An increase to packet size targets > > bandwidth rather than latency (speed). >=20 > Sure, but running =E2=80=98openssl speed=E2=80=99 on either aes-128-cbc o= r hmac or sha256 > (there=E2=80=99s no test for AES-GCM or ChaCha-poly) you get smallish dif= ferences > in terms of kilobytes per second between 1024-byte buffers and 8192-byte > buffers. And the difference going to be even smaller going to 16KB buffer= s, > let alone 64KB buffers. this is not valid comparison. openssl speed doesn't use the hardware accelerated codepath you need to use `openssl speed -evp aes-128-gcm` to see it (and yes,=20 aes-gcm and chacha20-poly1305 is supported then) What I see is nearly a 1GB/s throughput increase between 1024 and 8192 byte= blocks for AES-GCM: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 byt= es aes-128-gcm 614979.91k 1388369.31k 2702645.76k 3997320.76k 4932512.= 79k While indeed, for chacha20 there's little to no difference at the high end: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 byt= es 16384 bytes chacha20-poly1305 242518.50k 514356.72k 1035220.57k 1868933.46k 1993= 609.50k 1997438.98k (aes-128-gcm performance from openssl-1.0.2j-1.fc24.x86_64, chacha20-poly13= 05 from openssl master, both on=20 Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz) =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart3858735.CsNdxGDNAf Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYNu9pAAoJEJKo0bgB0vX1UUcP/iredwshbKs4djPU0MPSgL07 4Y3c1idP9wKPmPVkxiivCXu7nQVm2SGcp2cOpCtZovW0YVzMyfZ2Uftkr9rbejOL Se2n1rw9/FMGmkkcBATz/78tO4L89GYOAHeqHnNcb+Jp0PNEmVeZJPq8F7KU3M+h tv+4Eh75nqI3wk6RJKrb3Su6llWq7fDDS6r85GYsd8C3q+1r1EmUavu4BozPHlP/ uUwgSRBwLHMafjOsPq1Y/WLY3aooKzZBBaPtL2I7XHVGIpknujxIMQuxUJjAUAm/ m04b0Syz0JDmZ99Zxwm3RPtMsBJkrtpFpESZPxOr9lCjIFO8/8bv7b53JZz+QfIs lJ3it1tLbp5o4WAMKlB60n1nizlqb5JrzZzmQQaSYdBwLnrwDkarvoj3TVMxtpuk I+wPgmI+QHhLoVn7BghZm+8pMFfgHKsTWKxnRDwDD0xFzxLhy0zUPoEKvUpu55gw Ik3aWzZlr12VeqSqc5yXZUNRH+BV3cgFByZVtaEaQ2PNvE+yyjEPKRWyKbx+Yl8H TLxQeJl59Et6renZU3ljNtY00+Qsk3ubcPVgot1sSAZrr5LpqjddBttCOXPvLC0X O/a/ijQ8/nc2xcMsnSjiZEdP8XL+k/Nah6R0ODiBteairfpPrxEh5W6aqbj33ic9 sLGszj28yhG/hkPRq5ne =/06v -----END PGP SIGNATURE----- --nextPart3858735.CsNdxGDNAf-- From nobody Thu Nov 24 06:16:52 2016 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 33C611295EF for ; Thu, 24 Nov 2016 06:16:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVW2PvgnFsTc for ; Thu, 24 Nov 2016 06:16:46 -0800 (PST) Received: from mail-wj0-x236.google.com (mail-wj0-x236.google.com [IPv6:2a00:1450:400c:c01::236]) (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 36144129548 for ; Thu, 24 Nov 2016 06:16:46 -0800 (PST) Received: by mail-wj0-x236.google.com with SMTP id qp4so34552102wjc.3 for ; Thu, 24 Nov 2016 06:16:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DqMZXUN+RjSsPGF4rTLcg3hNNnbvZk+QvuJZPNyph/8=; b=voqafJ3x0AK8eOFP8TEbw/T1f3bg1T70qYXRZJ3LMGzKqNcO3jXRx6khDaW40eimIL x14+ygdN0/jsYD3Q5eyZzwV48aH0PpC4dRWR4RW1KF2QIxR605VVnTf3ofgB3TNr7bcb qg4tZivMse6pmr6BGSoY1+0rIiq3VmCYM39Tbm8M6oiUwzzc7Lfdapqno5F+MrtV45Rq qfXzRhzuL1PzUDYbchbsKIHxCgY+rgvsBjBEOFrt+qBK60PBX3hKDqryHFfHi4NPJPKJ 6eglZHHXuiVeuA2yd3JXOjTlPpk3efE0tiLtNAl2Pu3MHiKF4u34Y2wy2tY8tJ1Ifykk GgQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=DqMZXUN+RjSsPGF4rTLcg3hNNnbvZk+QvuJZPNyph/8=; b=ZV0PqADx71o6MGxZnME/O0qy+bXcb9yfy4l7x296zfBHkYepGHKX6RLC4tnlFs/Eda MJWMZE4ncbtZiEL0Ir8udpJo1MH8WOn8wHYkHh7kEBl6iGtHf9OO/szzBD8zJpwEyGw1 gL6YrboDuL15kYaLvkz1rIOIu/D/8RCJDxArUz305e2BNSoqHi2ikybB1nc+RiKFw6Lp hYRw1Tp9OyXQK4+eXsj6iAgClafib3uWgCVTueOMmrY1pDnzxibFVFN3/tjUa5pAJZ0f dll2PRULS6HDOAbiuOw3Mlpi3EDBV7esGdIX3l/NEFRwbsegHHx7cJN8JPYMf7Hga6+S PlWg== X-Gm-Message-State: AKaTC03fwUjW90LlQJNb00jkhHVGjICbPmM+urtiXSwpo8nUdZDo+Sv8WuBi9sy1czgu6A== X-Received: by 10.194.191.201 with SMTP id ha9mr2517401wjc.205.1479997004718; Thu, 24 Nov 2016 06:16:44 -0800 (PST) Received: from [172.24.249.41] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id b7sm42070847wjm.39.2016.11.24.06.16.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Nov 2016 06:16:44 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Yoav Nir In-Reply-To: <2015444.TtsXi0aiky@pintsize.usersys.redhat.com> Date: Thu, 24 Nov 2016 16:16:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> <2015444.TtsXi0aiky@pintsize.usersys.redhat.com> To: Hubert Kario X-Mailer: Apple Mail (2.3251) Archived-At: Cc: "" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 14:16:49 -0000 > On 24 Nov 2016, at 15:47, Hubert Kario wrote: >=20 > On Wednesday, 23 November 2016 10:50:37 CET Yoav Nir wrote: >> On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos = wrote: >>> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >>>> Hi, Nikos >>>>=20 >>>> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos >>> That to my understanding is a way to reduce >>> latency in contrast to cpu costs. An increase to packet size targets >>> bandwidth rather than latency (speed). >>=20 >> Sure, but running =E2=80=98openssl speed=E2=80=99 on either = aes-128-cbc or hmac or sha256 >> (there=E2=80=99s no test for AES-GCM or ChaCha-poly) you get smallish = differences >> in terms of kilobytes per second between 1024-byte buffers and = 8192-byte >> buffers. And the difference going to be even smaller going to 16KB = buffers, >> let alone 64KB buffers. >=20 > this is not valid comparison. openssl speed doesn't use the hardware > accelerated codepath >=20 > you need to use `openssl speed -evp aes-128-gcm` to see it (and yes,=20= > aes-gcm and chacha20-poly1305 is supported then) >=20 > What I see is nearly a 1GB/s throughput increase between 1024 and 8192 = byte blocks for AES-GCM: >=20 > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes > aes-128-gcm 614979.91k 1388369.31k 2702645.76k 3997320.76k = 4932512.79k >=20 > While indeed, for chacha20 there's little to no difference at the high = end: > type 16 bytes 64 bytes 256 bytes 1024 bytes = 8192 bytes 16384 bytes > chacha20-poly1305 242518.50k 514356.72k 1035220.57k 1868933.46k = 1993609.50k 1997438.98k >=20 > (aes-128-gcm performance from openssl-1.0.2j-1.fc24.x86_64, = chacha20-poly1305 from openssl master, both on=20 > Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz) Cool. So you got a 23% improvement, and I got an 18% improvement for = AES-GCM. I still claim (but cannot prove without modifying openssl code = (maybe I=E2=80=99ll do that over the weekend) that the jump from 16KB to = 64KB will be far, far less pronounced. Yoav From nobody Thu Nov 24 06:37:55 2016 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 A2918129527 for ; Thu, 24 Nov 2016 06:37:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=allcosts-net.20150623.gappssmtp.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 Li7ElKJ7E3SS for ; Thu, 24 Nov 2016 06:37:53 -0800 (PST) Received: from mail-yw0-x230.google.com (mail-yw0-x230.google.com [IPv6:2607:f8b0:4002:c05::230]) (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 8961B129475 for ; Thu, 24 Nov 2016 06:37:53 -0800 (PST) Received: by mail-yw0-x230.google.com with SMTP id r204so40771716ywb.0 for ; Thu, 24 Nov 2016 06:37:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=allcosts-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=XO8dbytLsP9HEogFSk7Z3PS9pUBQilyitI1TCJE2sAs=; b=HMVtOoRoCzwonsKjhRa5G0vz3dOvOV0axZ38KCQMcznEiHTBYfPq3hRNqcYFv6qdw6 zCIwWvmMcIyTAKEFwElxppcspazByz+AfWumiwbziEdjVRByxxQRbdaIvVv59ntrU3Bq uOs43dHn7iKYOS927ub6NZxChmFPerkvLukJKbqkxKIgEq50fxCGy7dtTvBXHZ44Xp6d 6ixj2+SoxBO/ijriKH+cLLnSkK+Scw0U8TpG/4zPkZo4/48Dm/7QS8ob5ITCBqghuP7z weSuwLtzE8gNc6eZtvdAGQslYuHWxyO+q7HcIx3yWz51KFCe7B6ow4TGFGJRzJg37OvA N60Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XO8dbytLsP9HEogFSk7Z3PS9pUBQilyitI1TCJE2sAs=; b=eEYzTiLXMu+csDQvb30+raVW+XW0/0kr697BcZLu+dcXTcyqHWaUMMtBySEQ1+EDAh YaZMwKSUZHUtWRKSDpNXMKpTcFSDwMlzLGdvbSomZD8LG84GhU3tmokLJ3M5t65FiOX5 uJcjLmnCOGvyoYX5l2ayKbkOpn4RuWJrwkn6E7B6Pdsr+2lncKYhHLTrSO1JhDNYSaH4 nn8qPxyx5oNQGrqX5qoHHhBKPMW5Wbzi982WjE0lkKxmhUBShO924VxbUZAEe0udG8Pd o+Rjwn4emWUKac9538X56sJWZmhDaDRhfcEXeVAtMka6wp/Fr3rzPmPhjNXhvgfGL5zh WFSg== X-Gm-Message-State: AKaTC00bZ2r4DGtI/oKrlE6kCX82QJutNo81WM/rZwhYkfRl/blTzwS/EH8rOONEfIpAWmdGX3zchQ06mVwbsA== X-Received: by 10.13.198.71 with SMTP id i68mr4087071ywd.158.1479998272817; Thu, 24 Nov 2016 06:37:52 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.115.3 with HTTP; Thu, 24 Nov 2016 06:37:52 -0800 (PST) In-Reply-To: <095e01d2461e$4335acc0$c9a10640$@huitema.net> References: <095e01d2461e$4335acc0$c9a10640$@huitema.net> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Thu, 24 Nov 2016 06:37:52 -0800 Message-ID: To: Christian Huitema Content-Type: multipart/alternative; boundary=001a114e53da5250e305420cf387 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Additional warnings on 0-RTT data X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 14:37:54 -0000 --001a114e53da5250e305420cf387 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Nov 23, 2016 at 10:44 PM, Christian Huitema wrote: > On Wednesday, November 23, 2016 7:20 PM, Colm MacC=C3=A1rthaigh wrote: > > > > Prior to TLS1.3, replay is not possible, so the risks are new, but the > end-to-end designers > > may not realize to update their threat model and just what is required= . > I'd like to spell > > that out more than what's where at present. > > Uh? Replay was always possible, at the application level. Someone might > for example click twice on the same URL, opening two tabs, closing one at > random. And that's without counting on deliberate mischief. > Much more than browsers use TLS, and also more than HTTP. There are many web service APIs that rely on TLS for anti-replay, and do not simple retry requests. Transaction and commit protocols for example will usually have unique IDs for each attempt. But even if this were not the case, there are other material differences that are still relevant even to browsers. Firstly, an attacker can replay 0-RTT data at a vastly higher rate than they could ever cause a browser to do anything. Second, they can replay 0-RTT data to arbitrary nodes beyond what the browser may select. Together these open new attacks, like the third example I provided. --=20 Colm --001a114e53da5250e305420cf387 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 23, 2016 at 10:44 PM, Christian Huitema &= lt;huitema@huitema= .net> wrote:
On Wednesday, November 23, 2016 7:20 PM, Colm MacC=C3=A1rthaigh wrote: >
> Prior to TLS1.3, replay is not possible, so the risks are new, but the= end-to-end designers
> may not=C2=A0 realize to update their threat model and just what is re= quired. I'd like to spell
> that out more than what's where at present.

Uh? Replay was always possible, at the application level. Someone mi= ght for example click twice on the same URL, opening two tabs, closing one = at random. And that's without counting on deliberate mischief.

Much more than browsers use TLS, and also more = than HTTP. There are many web service APIs that rely on TLS for anti-replay= , and do not simple retry requests. Transaction and commit protocols for ex= ample will usually have unique IDs for each attempt.

But even if this were not the case, there are other material differences= that are still relevant even to browsers. Firstly, an attacker can replay = 0-RTT data at a vastly higher rate than they could ever cause a browser to = do anything. Second, they can replay 0-RTT data to arbitrary nodes beyond w= hat the browser may select. Together these open new attacks, like the third= example I provided.=C2=A0

--
Colm
--001a114e53da5250e305420cf387-- From nobody Thu Nov 24 07:42:05 2016 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 8EBDE129888 for ; Thu, 24 Nov 2016 07:42:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.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 eC5Gk8EPqZO0 for ; Thu, 24 Nov 2016 07:42:00 -0800 (PST) Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::233]) (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 6CA51129655 for ; Thu, 24 Nov 2016 07:41:42 -0800 (PST) Received: by mail-pg0-x233.google.com with SMTP id x23so19743326pgx.1 for ; Thu, 24 Nov 2016 07:41:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LGrn09NobWEohfSGlqwDuUE6PQqt2vPWCzkRNYoakLo=; b=xZCXIXX7PpUg/+NWYd7oMohTcU08up8YCdiLLZ7n53mR/HPDd6jFMQsIF25gKMMvSC i+vKAie39BqohmzSIsTybiKf02wTZNiEMIwYS+9B6i5TXWLML/2Cn+o6tTaC++qQxXIt YHnOTA/q8q+2mxsXXJo69tmjftAtGC1BakUYk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LGrn09NobWEohfSGlqwDuUE6PQqt2vPWCzkRNYoakLo=; b=Ki0bIz3nWKB9kZsBnlPAJesOo559EXDgGLoCBWDFK9IlrSlZ5nnEQwk/HKQQX/1EG/ hKjXTjtt0XaOf5AP19cK+fAYwwv6Vo4ESF1zD5+HQGyn2WFNciI3AacMEghSLbEO5bjp DVoHCdBq2KEHs9+hFBlY6rgexIGQW5wp+J+zCGxyHROhbdkyRinD32yjBfYDzUm2BKkZ 9X5Y5F1cYhF1uPnOpqfF5n4ga0t+x+o2EXZLyLFVao4J8zOsqLkZR5IoD3SDZtf9iPX7 Mjr+mZWWkEurXxFK+QHA0AeQZ6pKTc/SDGEE8i0mNPuzeL9j0FnJGjzr9M58MDD38cFi 2SNA== X-Gm-Message-State: AKaTC00jSOQjIiDRDQ3BGyO7HGVcJ2Bn/pqlHwYkJG73fWnF6AkU1g/Bdj0TWZRinkD5WYRD X-Received: by 10.99.164.9 with SMTP id c9mr5308459pgf.141.1480002101619; Thu, 24 Nov 2016 07:41:41 -0800 (PST) Received: from ?IPv6:2601:645:8302:ef30:6dd1:b721:198b:ae4? ([2601:645:8302:ef30:6dd1:b721:198b:ae4]) by smtp.gmail.com with ESMTPSA id v76sm61314839pfk.77.2016.11.24.07.41.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 24 Nov 2016 07:41:41 -0800 (PST) Content-Type: text/plain; charset=windows-1251 Mime-Version: 1.0 (1.0) From: Vlad Krasnov X-Mailer: iPhone Mail (14A456) In-Reply-To: Date: Thu, 24 Nov 2016 07:41:39 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <3F248E51-E4B7-45C1-96C3-E7A9FCA24490@cloudflare.com> References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> <2015444.TtsXi0aiky@pintsize.usersys.redhat.com> To: Yoav Nir Archived-At: Cc: "" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 15:42:04 -0000 A) OpenSSL does not measure the actual TLS performance (including nonce cons= truction, additional data, etc), but rather just the speed of the main encr= yption loop. B) Still, I agree with Yoav. =46rom my experience, the difference in TPT bet= ween 16K records and 64K records is negligible, as well as the network overh= ead. On the other hand using larger records increases the risk of HoL blocki= ng. Cheers, Vlad > On Nov 24, 2016, at 6:16 AM, Yoav Nir wrote: >=20 >=20 >> On 24 Nov 2016, at 15:47, Hubert Kario wrote: >>=20 >> On Wednesday, 23 November 2016 10:50:37 CET Yoav Nir wrote: >>>> On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos wro= te: >>>>> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >>>>> Hi, Nikos >>>>>=20 >>>>> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos >>>> That to my understanding is a way to reduce >>>> latency in contrast to cpu costs. An increase to packet size targets >>>> bandwidth rather than latency (speed). >>>=20 >>> Sure, but running =91openssl speed=92 on either aes-128-cbc or hmac or s= ha256 >>> (there=92s no test for AES-GCM or ChaCha-poly) you get smallish differen= ces >>> in terms of kilobytes per second between 1024-byte buffers and 8192-byte= >>> buffers. And the difference going to be even smaller going to 16KB buffe= rs, >>> let alone 64KB buffers. >>=20 >> this is not valid comparison. openssl speed doesn't use the hardware >> accelerated codepath >>=20 >> you need to use `openssl speed -evp aes-128-gcm` to see it (and yes,=20 >> aes-gcm and chacha20-poly1305 is supported then) >>=20 >> What I see is nearly a 1GB/s throughput increase between 1024 and 8192 by= te blocks for AES-GCM: >>=20 >> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 b= ytes >> aes-128-gcm 614979.91k 1388369.31k 2702645.76k 3997320.76k 493251= 2.79k >>=20 >> While indeed, for chacha20 there's little to no difference at the high en= d: >> type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 b= ytes 16384 bytes >> chacha20-poly1305 242518.50k 514356.72k 1035220.57k 1868933.46k 19= 93609.50k 1997438.98k >>=20 >> (aes-128-gcm performance from openssl-1.0.2j-1.fc24.x86_64, chacha20-poly= 1305 from openssl master, both on=20 >> Intel(R) Core(TM) i7-6600U CPU @ 2.60GHz) >=20 > Cool. So you got a 23% improvement, and I got an 18% improvement for AES-G= CM. I still claim (but cannot prove without modifying openssl code (maybe I=92= ll do that over the weekend) that the jump from 16KB to 64KB will be far, fa= r less pronounced. >=20 > Yoav >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Nov 24 11:50:39 2016 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 84D5A129C15 for ; Thu, 24 Nov 2016 11:50:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 h6DrA7hYygpn for ; Thu, 24 Nov 2016 11:50:34 -0800 (PST) Received: from brontes.bolet.org (brontes.bolet.org [62.210.214.227]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 063CC129C12 for ; Thu, 24 Nov 2016 11:50:33 -0800 (PST) Received: by brontes.bolet.org (Postfix, from userid 1000) id 638552082E; Thu, 24 Nov 2016 20:50:02 +0100 (CET) Date: Thu, 24 Nov 2016 20:50:02 +0100 From: Thomas Pornin To: tls@ietf.org Message-ID: <20161124195002.GA32346@bolet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [TLS] Maximum Fragment Length negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 19:50:36 -0000 Hello, I know that I am a bit late to the party, but I have a suggestion for the upcoming TLS 1.3. Context: I am interested in TLS support in constrained architectures, specifically those which have very little RAM. I recently published a first version of an implementation of TLS 1.0 to 1.2, that primarily targets that kind of system ( https://www.bearssl.org/ ); a fully functional TLS server can then run in as little as 25 kB of RAM (and even less of ROM, for the code itself). Out of these 25 kB, 16 kB are used for the buffer for incoming records, because encrypted records cannot be processed until fully received (data could be obtained from a partial record, but we must wait for the MAC before actually acting on the data) and TLS specifies that records can have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is directly related to that maximum fragment length. There is a defined extension (in RFC 6066) that allows a client to negotiate a smaller maximum fragment length. That extension is simple to implement, but it has two problems that prevent it from being really usable: 1. It is optional, so any implementation is free not to implement it, and in practice many do not (e.g. last time I checked, OpenSSL did not support it). 2. It is one-sided: the client may asked for a smaller fragment, but the server has no choice but to accept the value sent by the client. In situations where the constrained system is the server, the extension is not useful (e.g. the embedded system runs a minimal HTTPS server, for a Web-based configuration interface; the client is a Web browser and won't ask for a smaller maximum fragment length). I suggest to fix these issues in TLS 1.3. My proposal is the following: - Make Max Fragment Length extension support mandatory (right now, draft 18 makes it "recommended" only). - Extend the extension semantics **when used in TLS 1.3** in the following ways: * When an implementation supports a given maximum fragment length, it MUST also support all smaller lengths (in the list of lengths indicated in the extension: 512, 1024, 2048, 4096 and 16384). * When the server receives the extension for maximum length N, it may respond with the extension with any length N' <= N (in the list above). * If the client does not send the extension, then this is equivalent to sending it with a maximum length of 16384 bytes (so the server may still send the extension, even if the client did not). Semantics for the extension in TLS 1.2 and previous is unchanged. With these changes, RAM-constrained clients and servers can negotiate a maximum length for record plaintext that they both support, and such an implementation can use a small record buffer with the guarantee that all TLS-1.3-aware peers will refrain from sending larger records. With, for instance, a 2048-byte buffer, per-record overhead is still small (about 1%), and overall RAM usage is halved, which is far from negligible. RAM-constrained full TLS 1.3 is likely to be challenging (I envision issues with, for instance, cookies, since they can be up to 64 kB in length), but a guaranteed flexible negotiation for maximum fragment length would be a step in the right direction. Any comments / suggestions ? Thanks, --Thomas Pornin From nobody Thu Nov 24 13:10:13 2016 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 67D9B129D29 for ; Thu, 24 Nov 2016 13:10:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.902 X-Spam-Level: X-Spam-Status: No, score=-6.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 Po4I3gme7oIt for ; Thu, 24 Nov 2016 13:10:07 -0800 (PST) Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0976A129D30 for ; Thu, 24 Nov 2016 13:10:05 -0800 (PST) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id C872545028D50; Thu, 24 Nov 2016 21:09:59 +0000 (GMT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id uAOLA2NM014572 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 24 Nov 2016 21:10:03 GMT Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id uAOLA1UW031755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 24 Nov 2016 21:10:01 GMT Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.191]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0301.000; Thu, 24 Nov 2016 22:10:01 +0100 From: "Fossati, Thomas (Nokia - GB)" To: Thomas Pornin , "tls@ietf.org" Thread-Topic: [TLS] Maximum Fragment Length negotiation Thread-Index: AQHSRowOIV1E0dPWaUOfj79eLDdjL6DokFYA Date: Thu, 24 Nov 2016 21:10:00 +0000 Message-ID: References: <20161124195002.GA32346@bolet.org> In-Reply-To: <20161124195002.GA32346@bolet.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.0.161029 x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-ID: <3A1EF3386059ED41B3951CA222D09EA0@exchange.lucent.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Maximum Fragment Length negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 24 Nov 2016 21:10:11 -0000 Hi Thomas, We encountered the same issue and suggested something similar in [1] -- although not at the same level of detail as you below. I like your proposal, but I'm not convinced that overloading the semantics of an already existing extension when used in combination with a specific version of the protocol is necessarily the best strategy. Besides, I'd like to be able to deploy a similar mechanism in 1.2. So, why not simply allocating a new code-point for an extension with the semantics you describe and make it available across different protocol versions? Cheers, t [1]=20 https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00#section- 6 On 24/11/2016 19:50, "TLS on behalf of Thomas Pornin" wrote: >Hello, > >I know that I am a bit late to the party, but I have a suggestion for >the upcoming TLS 1.3. > >Context: I am interested in TLS support in constrained architectures, >specifically those which have very little RAM. I recently published a >first version of an implementation of TLS 1.0 to 1.2, that primarily >targets that kind of system ( https://www.bearssl.org/ ); a fully >functional TLS server can then run in as little as 25 kB of RAM (and >even less of ROM, for the code itself). > >Out of these 25 kB, 16 kB are used for the buffer for incoming records, >because encrypted records cannot be processed until fully received (data >could be obtained from a partial record, but we must wait for the MAC >before actually acting on the data) and TLS specifies that records can >have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is >directly related to that maximum fragment length. > >There is a defined extension (in RFC 6066) that allows a client to >negotiate a smaller maximum fragment length. That extension is simple >to implement, but it has two problems that prevent it from being >really usable: > > 1. It is optional, so any implementation is free not to implement it, > and in practice many do not (e.g. last time I checked, OpenSSL did > not support it). > > 2. It is one-sided: the client may asked for a smaller fragment, but > the server has no choice but to accept the value sent by the client. > In situations where the constrained system is the server, the > extension is not useful (e.g. the embedded system runs a minimal > HTTPS server, for a Web-based configuration interface; the client is > a Web browser and won't ask for a smaller maximum fragment length). > > >I suggest to fix these issues in TLS 1.3. My proposal is the following: > > - Make Max Fragment Length extension support mandatory (right now, > draft 18 makes it "recommended" only). > > - Extend the extension semantics **when used in TLS 1.3** in the >following > ways: > > * When an implementation supports a given maximum fragment length, it > MUST also support all smaller lengths (in the list of lengths > indicated in the extension: 512, 1024, 2048, 4096 and 16384). > > * When the server receives the extension for maximum length N, it > may respond with the extension with any length N' <=3D N (in the > list above). > > * If the client does not send the extension, then this is equivalent > to sending it with a maximum length of 16384 bytes (so the server > may still send the extension, even if the client did not). > > Semantics for the extension in TLS 1.2 and previous is unchanged. > >With these changes, RAM-constrained clients and servers can negotiate a >maximum length for record plaintext that they both support, and such an >implementation can use a small record buffer with the guarantee that all >TLS-1.3-aware peers will refrain from sending larger records. With, for >instance, a 2048-byte buffer, per-record overhead is still small (about >1%), and overall RAM usage is halved, which is far from negligible. > > >RAM-constrained full TLS 1.3 is likely to be challenging (I envision >issues with, for instance, cookies, since they can be up to 64 kB in >length), but a guaranteed flexible negotiation for maximum fragment >length would be a step in the right direction. > >Any comments / suggestions ? > >Thanks, > > > --Thomas Pornin > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > From nobody Fri Nov 25 00:28:49 2016 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 39FBF12A247; Fri, 25 Nov 2016 00:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 YYjU6Q8u0Xef; Fri, 25 Nov 2016 00:28:44 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BE17129B55; Fri, 25 Nov 2016 00:28:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1480062523; x=1511598523; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Ob1e7qye/6u42D0O7+KsZxvXBeFeBdPC55UaDwwEj4c=; b=dXqG59eSPnILzdp/9LPJKLS/Tej8Gbe7r5bzOlLJOMSZJ2EGTTJBXgEc 0LJyuObXa7wj7lSTD2UdxZVqEigyY1p0clTQlgf45RhNwXSQu6Hq+BMin KmdpSFUGk85QmcRdLRNGE5Me07tZcCT0J5vN9sWm4kpQsGkkw5YsU5/S3 HmxxbSa2fKlzm+4wyeBVO7/lUQD823R8tM0id/0R8/WXlwzToLCR2Z3l/ 8i64xe7Tgkz8ncSnqRJgkDDH9MNL65N5Zck9aTwi384XkzpNCsFibttQG MWsGxZkDFPiUuQwxTcnnSj2XaaWYrC603t6n2ylSjM4Gtivj5L1DYWn3m w==; X-IronPort-AV: E=Sophos;i="5.31,546,1473076800"; d="scan'208";a="117069894" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.2.4 - Outgoing - Outgoing Received: from uxcn13-ogg-c.uoa.auckland.ac.nz ([10.6.2.4]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 25 Nov 2016 21:28:42 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-ogg-c.UoA.auckland.ac.nz (10.6.2.4) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Fri, 25 Nov 2016 21:28:41 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Fri, 25 Nov 2016 21:28:41 +1300 From: Peter Gutmann To: RFC Errata System , "azet@azet.org" , "jsalowey@cisco.com" , "abhijitc@cisco.com" , "mcgrew@cisco.com" Thread-Topic: [TLS] [Errata Verified] RFC5288 (4694) Thread-Index: AQHSRlMl4eWUzSqUGk21L4EFUrUa66DpXtHc Date: Fri, 25 Nov 2016 08:28:41 +0000 Message-ID: <1480062511569.30705@cs.auckland.ac.nz> References: <20161124130308.AF3D3B8132E@rfc-editor.org> In-Reply-To: <20161124130308.AF3D3B8132E@rfc-editor.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "tls@ietf.org" , "iesg@ietf.org" Subject: Re: [TLS] [Errata Verified] RFC5288 (4694) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 25 Nov 2016 08:28:48 -0000 RFC Errata System writes:=0A= =0A= >The following errata report has been verified for RFC5288,=0A= >"AES Galois Counter Mode (GCM) Cipher Suites for TLS".=0A= =0A= I think the erratum needs an erratum. Firstly, nonce doesn't mean "number= =0A= used once". Secondly, nonce reuse doesn't just result in a failure of=0A= integrity-protection, it also results in a loss of confidentiality protecti= on.=0A= In other words it leads to total breach of the encryption mode's security,= =0A= both properties that it's supposed to provide are no longer present.=0A= =0A= Peter.=0A= From nobody Fri Nov 25 01:49:59 2016 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 94BD0129574 for ; Fri, 25 Nov 2016 01:49:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 0zCfshgwb7dx for ; Fri, 25 Nov 2016 01:49:53 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB2B912959B for ; Fri, 25 Nov 2016 01:49:50 -0800 (PST) Received: from [172.16.254.118] ([80.92.114.246]) by mail.gmx.com (mrgmx002 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MAPoQ-1bzn071x18-00BbTM for ; Fri, 25 Nov 2016 10:49:45 +0100 To: tls@ietf.org References: <20161124195002.GA32346@bolet.org> From: Hannes Tschofenig Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9 Message-ID: <8d507392-3fb3-82a3-8679-edb6a7e5970d@gmx.net> Date: Fri, 25 Nov 2016 10:49:44 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <20161124195002.GA32346@bolet.org> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="krFDMjvs465gtRBiBcv885MNKapkLKQrJ" X-Provags-ID: V03:K0:hV/1VNOl0PVu2e7w/m1LaTrOkewkXS5cxb1cTTzvWJZLvA1Z1a8 WW/vmTyxGb6/h1Hs15KkJxkDJvUR+Yw3OzC5n31KNyBp6CJZneTnq4EjxrCniWQgf9HSYvj lcL/AcE4vzK3J8Ilt1f0xeo3PTuyF2Iyl0iHdjnSoQ0EfQTPT50iHEfT+b71s92WfblvtXq 4gIbqq+SJQYflc64qtlZQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:rJh54WNhhoc=:7kN5q6B8kI22PmWk/2KyLo 9xZRo54+cN9rdPb4lauF2MH7fOsI4kxsIgFdXn9xWInnsLUBdoKXyp2PZEnp4BY45r+Kt7yKA MHZ9m6yp6csc4OVvKzKouH11HXLrsSD7yQKjNDdnVa/FCAVRhhTi/jHcZx1qBAXzbH1wmwRh5 6I4+PsGrp+2rLtfxZwwt+tiRgrTNoQJf9vvk8Ze95dW7vddvb3iwRHT1rs0LmnEiyiWGptR9p YKqunv3eGo3zhl+JZT0mjKaUPK/QgEgZxz7IjaPNjma6LqPa/HUxEsx5vALNgXWcJQx/Tzkin wVBE0VSQ/x5VabsRtI6vINngWY999jnk5gL3J3KaSM6PtbsKrgQOZbiIFKtQEcaUsbrWTmsFB DTA2f9GEU3ldY5IpEO+awiEQH73ouojQtbP3WgqDhKqyykK9G38appG30CJ3jZ3DSWIH+O9T0 Pm3GAyg+O/NDSI5sOluoFsTEw8XvRiivKiXh/slZ9NMXLsKUFo9oNLo64mDCYcNYtpgOf11R8 tqNo6DCVdu/WX8zXNoLSsIBSufe2ezw9UuN0b7UDHkgA05aQVVK8qxkZpRlKjpJ7HGwB5/pTx l2HfLnuEdRUe6aAH8eOphVD/KsA45zXYxo+JEYSMyiiw89cBSxZWxSP8KE/NPj5kiKToffLKZ g8sxlKn9RWnxy8NEGDrDTPbnX0T2TthOh+NPWwmaE6rK+q7M1z2qBW1H65hqj7uZ8/NdH0Dj4 JDNcFS3pwnBf89ULP/N+USoYlt6Rf+fo/7CKpAVLinFA3FBv0Z17KPukq3kqegFuoyVu8HQzH rtZCrSN Archived-At: Subject: Re: [TLS] Maximum Fragment Length negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 25 Nov 2016 09:49:58 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --krFDMjvs465gtRBiBcv885MNKapkLKQrJ Content-Type: multipart/mixed; boundary="A42JU3QNvdP4nBVKtqBGtiiV625cG3gx1"; protected-headers="v1" From: Hannes Tschofenig To: tls@ietf.org Message-ID: <8d507392-3fb3-82a3-8679-edb6a7e5970d@gmx.net> Subject: Re: [TLS] Maximum Fragment Length negotiation References: <20161124195002.GA32346@bolet.org> In-Reply-To: <20161124195002.GA32346@bolet.org> --A42JU3QNvdP4nBVKtqBGtiiV625cG3gx1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Thomas, your observations are in line with what we had noticed as well, see Section 6 of https://tools.ietf.org/html/draft-fossati-tls-iot-optimizations-00 Ciao Hannes On 11/24/2016 08:50 PM, Thomas Pornin wrote: > Hello, >=20 > I know that I am a bit late to the party, but I have a suggestion for > the upcoming TLS 1.3. >=20 > Context: I am interested in TLS support in constrained architectures, > specifically those which have very little RAM. I recently published a > first version of an implementation of TLS 1.0 to 1.2, that primarily > targets that kind of system ( https://www.bearssl.org/ ); a fully > functional TLS server can then run in as little as 25 kB of RAM (and > even less of ROM, for the code itself). >=20 > Out of these 25 kB, 16 kB are used for the buffer for incoming records,= > because encrypted records cannot be processed until fully received (dat= a > could be obtained from a partial record, but we must wait for the MAC > before actually acting on the data) and TLS specifies that records can > have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage i= s > directly related to that maximum fragment length. >=20 > There is a defined extension (in RFC 6066) that allows a client to > negotiate a smaller maximum fragment length. That extension is simple > to implement, but it has two problems that prevent it from being > really usable: >=20 > 1. It is optional, so any implementation is free not to implement it, > and in practice many do not (e.g. last time I checked, OpenSSL did > not support it). >=20 > 2. It is one-sided: the client may asked for a smaller fragment, but > the server has no choice but to accept the value sent by the client= =2E > In situations where the constrained system is the server, the > extension is not useful (e.g. the embedded system runs a minimal > HTTPS server, for a Web-based configuration interface; the client i= s > a Web browser and won't ask for a smaller maximum fragment length).= >=20 >=20 > I suggest to fix these issues in TLS 1.3. My proposal is the following:= >=20 > - Make Max Fragment Length extension support mandatory (right now, > draft 18 makes it "recommended" only). >=20 > - Extend the extension semantics **when used in TLS 1.3** in the follo= wing > ways: >=20 > * When an implementation supports a given maximum fragment length, i= t > MUST also support all smaller lengths (in the list of lengths > indicated in the extension: 512, 1024, 2048, 4096 and 16384). >=20 > * When the server receives the extension for maximum length N, it > may respond with the extension with any length N' <=3D N (in the > list above). >=20 > * If the client does not send the extension, then this is equivalent= > to sending it with a maximum length of 16384 bytes (so the server > may still send the extension, even if the client did not). >=20 > Semantics for the extension in TLS 1.2 and previous is unchanged. >=20 > With these changes, RAM-constrained clients and servers can negotiate a= > maximum length for record plaintext that they both support, and such an= > implementation can use a small record buffer with the guarantee that al= l > TLS-1.3-aware peers will refrain from sending larger records. With, for= > instance, a 2048-byte buffer, per-record overhead is still small (about= > 1%), and overall RAM usage is halved, which is far from negligible. >=20 >=20 > RAM-constrained full TLS 1.3 is likely to be challenging (I envision > issues with, for instance, cookies, since they can be up to 64 kB in > length), but a guaranteed flexible negotiation for maximum fragment > length would be a step in the right direction. >=20 > Any comments / suggestions ? >=20 > Thanks, >=20 >=20 > --Thomas Pornin >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 --A42JU3QNvdP4nBVKtqBGtiiV625cG3gx1-- --krFDMjvs465gtRBiBcv885MNKapkLKQrJ Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJYOAk4AAoJEGhJURNOOiAtfqUH/2oAExMWTAZbXx3jPhQSiUzM AJqbbAdnXeF4SlHxLgGvyDcv/qGWMqeze2NkrfZO4gE0FYgjxrA2pw7R+j0Niuj8 crOIDM9AolU91p1hy0wQzR5OKkZRbVRTy/89pJvY9VWBxnjoRkDDOWOAI0UxdS0H e/j4HYzvPipPsAOHYkxbB+uNOCRQyLCpEfzoyjBCw+AAB9tYgWIR1rW2YdIdmKqu IBy72bUgbsz1Jm6IZQ7xY3GkUySl6aO5GY8LV4ZnFaPnqfk6GEkw8iDS0UzVHBnr 9++9hw7c53+NIGe4Q/shzCDmGBGSGuv2STAlXBQ4kRbr3PY05RlCEi8+4xfcTKY= =1enx -----END PGP SIGNATURE----- --krFDMjvs465gtRBiBcv885MNKapkLKQrJ-- From nobody Fri Nov 25 03:39:40 2016 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 BC2DB12A2B2 for ; Fri, 25 Nov 2016 03:39:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no 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 npU_Vj-i5tmm for ; Fri, 25 Nov 2016 03:39:34 -0800 (PST) Received: from drew.franken.de (mail-n.franken.de [193.175.24.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBF8612A4B0 for ; Fri, 25 Nov 2016 03:17:07 -0800 (PST) Received: from [192.168.1.101] (p508F0EA0.dip0.t-ipconnect.de [80.143.14.160]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTPSA id B6DEE72106C2A; Fri, 25 Nov 2016 12:17:01 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\)) From: Michael Tuexen In-Reply-To: <20161124195002.GA32346@bolet.org> Date: Fri, 25 Nov 2016 12:17:01 +0100 Content-Transfer-Encoding: 7bit Message-Id: <1FA4FB92-3105-4514-8F53-21AD15B28295@lurchi.franken.de> References: <20161124195002.GA32346@bolet.org> To: Thomas Pornin X-Mailer: Apple Mail (2.3251) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Maximum Fragment Length negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 25 Nov 2016 11:39:39 -0000 > On 24 Nov 2016, at 20:50, Thomas Pornin wrote: > > Hello, > > I know that I am a bit late to the party, but I have a suggestion for > the upcoming TLS 1.3. > > Context: I am interested in TLS support in constrained architectures, > specifically those which have very little RAM. I recently published a > first version of an implementation of TLS 1.0 to 1.2, that primarily > targets that kind of system ( https://www.bearssl.org/ ); a fully > functional TLS server can then run in as little as 25 kB of RAM (and > even less of ROM, for the code itself). > > Out of these 25 kB, 16 kB are used for the buffer for incoming records, > because encrypted records cannot be processed until fully received (data > could be obtained from a partial record, but we must wait for the MAC > before actually acting on the data) and TLS specifies that records can > have up to 16384 bytes of plaintext. Thus, about 2/3 of the RAM usage is > directly related to that maximum fragment length. > > There is a defined extension (in RFC 6066) that allows a client to > negotiate a smaller maximum fragment length. That extension is simple > to implement, but it has two problems that prevent it from being > really usable: > > 1. It is optional, so any implementation is free not to implement it, > and in practice many do not (e.g. last time I checked, OpenSSL did > not support it). > > 2. It is one-sided: the client may asked for a smaller fragment, but > the server has no choice but to accept the value sent by the client. > In situations where the constrained system is the server, the > extension is not useful (e.g. the embedded system runs a minimal > HTTPS server, for a Web-based configuration interface; the client is > a Web browser and won't ask for a smaller maximum fragment length). > > > I suggest to fix these issues in TLS 1.3. My proposal is the following: > > - Make Max Fragment Length extension support mandatory (right now, > draft 18 makes it "recommended" only). > > - Extend the extension semantics **when used in TLS 1.3** in the following > ways: > > * When an implementation supports a given maximum fragment length, it > MUST also support all smaller lengths (in the list of lengths > indicated in the extension: 512, 1024, 2048, 4096 and 16384). > > * When the server receives the extension for maximum length N, it > may respond with the extension with any length N' <= N (in the > list above). > > * If the client does not send the extension, then this is equivalent > to sending it with a maximum length of 16384 bytes (so the server > may still send the extension, even if the client did not). > > Semantics for the extension in TLS 1.2 and previous is unchanged. > > With these changes, RAM-constrained clients and servers can negotiate a > maximum length for record plaintext that they both support, and such an > implementation can use a small record buffer with the guarantee that all > TLS-1.3-aware peers will refrain from sending larger records. With, for > instance, a 2048-byte buffer, per-record overhead is still small (about > 1%), and overall RAM usage is halved, which is far from negligible. > > > RAM-constrained full TLS 1.3 is likely to be challenging (I envision > issues with, for instance, cookies, since they can be up to 64 kB in > length), but a guaranteed flexible negotiation for maximum fragment > length would be a step in the right direction. > > Any comments / suggestions ? Can we extend this in a way that you can also increase the maximum fragment length. So if the client requests a larger value and the server is willing to do so, it can be used? Best regards Michael > > Thanks, > > > --Thomas Pornin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Fri Nov 25 04:09:11 2016 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 498C1129E1D for ; Fri, 25 Nov 2016 04:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.397 X-Spam-Level: X-Spam-Status: No, score=-3.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497] autolearn=ham autolearn_force=no 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 Ed6VlWez430g for ; Fri, 25 Nov 2016 04:09:05 -0800 (PST) Received: from wizmail.org (wizmail.org [IPv6:2a00:1940:107::2:0:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C4AC12A2DD for ; Fri, 25 Nov 2016 03:43:25 -0800 (PST) Received: from [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) by wizmail.org with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87_RC123) id 1cAEuX-0000fV-QN for tls@ietf.org (return-path ); Fri, 25 Nov 2016 11:43:21 +0000 To: tls@ietf.org References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <182CAE27-5A08-45FB-BC4D-D9397FFB5EF8@gmail.com> <66c428f3-33a9-3a19-7ec7-b090d6a3831a@wizmail.org> From: Jeremy Harris Message-ID: <36a2f62f-71d1-c175-fb22-3185606024d8@wizmail.org> Date: Fri, 25 Nov 2016 11:43:21 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Pcms-Received-Sender: [2a00:b900:109e:0:c5d6:c61b:f5e0:b51f] (helo=lap.dom.ain) with esmtpsa Archived-At: Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 25 Nov 2016 12:09:10 -0000 On 23/11/16 19:13, Watson Ladd wrote: > On Nov 23, 2016 10:22 AM, "Jeremy Harris" wrote: >> >> On 23/11/16 08:50, Yoav Nir wrote: >>> As long as you run over a network that has a smallish MTU, you’re going > to incur the packetization costs anyway, either in your code or in > operating system code. If you have a 1.44 GB file you want to send, it’s > going to take a million IP packets either way and 100 million AES block > operations. >> >> Actually, no. Everybody offloads ether-frame packetization and TCP >> re-segmentation to the NIC, talking 64kB TCP segments across the NIC/OS >> boundary. > > Who is 'everybody'? Broadcom, Intel, Emulex... anyone producing a high speed NIC. Perhaps we're talking past each other; I'm referring to (usually TCP) offload. > Let's look at the cost more exactly. We always have to copy from the > storage to the network. Packetization copies a tiny bit more data on each > packet. The amount of extra data doesn't hurt, having to deal with a larger number of buffers does - especially on receive, with reassembly. -- Jeremy From nobody Fri Nov 25 07:02:38 2016 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 24185129854 for ; Fri, 25 Nov 2016 07:02:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.098 X-Spam-Level: X-Spam-Status: No, score=-4.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 za7CA74rNLWV for ; Fri, 25 Nov 2016 07:02:31 -0800 (PST) Received: from smtp-p02.blackberry.com (smtp-p02.blackberry.com [208.65.78.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1BD129FD4 for ; Fri, 25 Nov 2016 06:43:35 -0800 (PST) Received: from xct105cnc.rim.net ([10.65.161.205]) by mhs213cnc.rim.net with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Nov 2016 09:43:33 -0500 Received: from XMB116CNC.rim.net ([fe80::45d:f4fe:6277:5d1b]) by XCT105CNC.rim.net ([fe80::d13d:b7a2:ae5e:db06%16]) with mapi id 14.03.0319.002; Fri, 25 Nov 2016 09:43:33 -0500 From: Dan Brown To: "tls@ietf.org" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFZSX3LzrapIkar/s/Es63GbKDi+vqAgALvxwCAA9j5oA== Date: Fri, 25 Nov 2016 14:43:32 +0000 Message-ID: <810C31990B57ED40B2062BA10D43FBF501083213@XMB116CNC.rim.net> References: <201611221706.50692.davemgarrett@gmail.com> In-Reply-To: <201611221706.50692.davemgarrett@gmail.com> Accept-Language: en-US, en-CA Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.160.246] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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, 25 Nov 2016 15:02:36 -0000 I don't oppose any of the 4 given options, but I slightly prefer TLS 2.0, i= t seems simple and clear. =20 In my opinion, the whole SSL vs TLS confusion needs better education to con= front, version numbers (even dates) alone might not be enough. Renaming *S= SL products to *TLS should help. Avoiding "SSL/TLS" might help. Since others have proposed new options, how about TLS 2.017? Using the date= has benefits, but the actual crypto changes are much more important, so th= e decimal makes that point. An old crypto principle is that older is bette= r (among equally unbroken options) -- but naming new stuff is just not enou= gh to rid us of broken old stuff, so putting dates in names might not under= mine this principle. For future naming, on minor changes (or even pre-sche= duled reviews with no changes), update the date part, on major changes, sta= rt from scratch (as in 3.2024, or even use different letters ... ). =20 By the way, I'm sorry if my opinion diverges from the currently forming con= sensus. Just my $0.02. =20 Dan PS Just to be clear, if votes are to be tallied, my vote on this issue shou= ld be weighted quite low (i.e. 0, unless other votes are weighted low too, = and some kind of tie-breaker is needed), for at least three reasons: I have= not followed the TLS 1.3/2.0 spec closely (i.e., I had no part in building= the shed); I have nearly zero experience dealing with user interpretation = (i.e. marketing) of protocol names; my preference is weak. (Enough to deser= ve a negative weight, if that were not cheatable;) PPS I've said before that I prefer TLC(rypto) to TLS(ecurity), but that's u= nlikely to fly, and it may be okay to grandfather this tradition. (I hope = names of future crypto protocols (that TLS WG might work on) can be more sp= ecific and realistic.) -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Dave Garrett Sent: Tuesday, November 22, 2016 5:07 PM To: tls@ietf.org Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* (replies to a bunch of ideas in this thread) As the person who lit the match under this latest bikeshed debate, personal= ly, I don't see a strong consensus building here. Leaving the bikeshed unpa= inted seems like the option we're headed for, at this rate. I'm fine with T= LS 1.3 if that's the result here. That said, I think I've been somewhat swayed to the TLS 4 camp with the "fo= urth version of TLS" message. It makes a kind of messy sense that's kind of= fitting for TLS. I'm no longer against it. I've also suggested highlighting the year in the past, but only in the cont= ext of the title and messaging, not actually replacing the version number i= tself. I'd be ok with TLS 1.3-2017 (or something), not doing a find/replace= of 1.3 and changing it to 2017, wholesale. That just feels even more confu= sing. Lastly, I am vehemently against the suggestion of ditching the TLS name in = favor of SSL again, as was also brought up in this thread. SSL is dead and = insecure, and that message needs to stay. We need to get people to stop con= flating the two and making this worse, not accepting it. Dave On Sunday, November 20, 2016 08:16:07 pm Eric Rescorla wrote: > I mildly prefer TLS 1.3 to TLS 2 and TLS 4 (If we're going to rev the=20 > major version number we should abandon the minor one). > TLS 2017 strikes me as quite bad; we're certainly not planning to do a=20 > TLS 2018. I am strongly opposed to TLS 2017. >=20 > -Ekr >=20 >=20 > On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner wrote: >=20 > > At IETF 97, the chairs lead a discussion to resolve whether the WG=20 > > should rebrand TLS1.3 to something else. Slides can be found @ > > https://www.ietf.org/proceedings/97/slides/slides- > > 97-tls-rebranding-aka-pr612-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and=20 > > to not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm=20 > > this decision on the list so please let the list know your top choice b= etween: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Sat Nov 26 17:54:44 2016 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 434BD1294B2 for ; Sat, 26 Nov 2016 17:54:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me 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 ZFOyzQ6yp0t2 for ; Sat, 26 Nov 2016 17:54:41 -0800 (PST) Received: from marceline.ghedini.me (marceline.ghedini.me [151.236.26.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58E61129420 for ; Sat, 26 Nov 2016 17:54:41 -0800 (PST) Received: from localhost (82-69-45-54.dsl.in-addr.zen.co.uk [82.69.45.54]) by marceline.ghedini.me (Postfix) with ESMTPSA id 38D22230B8 for ; Sun, 27 Nov 2016 01:54:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ghedini.me; s=mail; t=1480211679; bh=Cqmo7Bf/CmiYRcFvdNV8SLHP15mvtatbB110POo2Lb0=; h=Date:From:To:Subject:From; b=Rv1kGPKqJheVsSuZWZBE0LRaDS1Pn7KqDJPcvrnlatPM+YsFobq7+8REhvwbUdq5T WIgtjjxh/xJ0gRRG2hJD07YtyU9KvHNlFyypZiJJKeZ5YiFKkLHOZjaCfY3M4KORfP Qar4OZquiYbXtAbtEIVw47rIvhWNQW2T2ekW3kJE= Date: Sun, 27 Nov 2016 01:54:37 +0000 From: Alessandro Ghedini To: tls@ietf.org Message-ID: <20161127015437.kfcwpemeppg3yw7h@pinky.local> Mail-Followup-To: tls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: NeoMutt/20161104 (1.7.1) Archived-At: Subject: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 27 Nov 2016 01:54:43 -0000 Hello, not sure if this has been discussed before (apologies if it has). QUIC mandates that certificate chains be gzip compressed in order to reduce the amount of bytes transmitted during full handshake. The QUIC crypto document says: Any remaining certificates are gzip compressed with a pre-shared dictionary that consists of the certificates specified by either of the first two methods, and a block of common strings from certificates taken from the Alexa top 5000. https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDwvZ5L6g/edit#heading=h.fgd4sj5avil0 Has anyone though about including something like that in TLS 1.3? Given that certificates usually take up most of the bytes exchanged during a full handshake it seems this could be useful, but I don't know if in practice the benefits are worth the added complexity. Thoughts? Cheers From nobody Sat Nov 26 18:03:54 2016 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 B462B1293FE for ; Sat, 26 Nov 2016 18:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 VRdX7ac557B8 for ; Sat, 26 Nov 2016 18:03:52 -0800 (PST) Received: from mail-yw0-x229.google.com (mail-yw0-x229.google.com [IPv6:2607:f8b0:4002:c05::229]) (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 1A5F3129459 for ; Sat, 26 Nov 2016 18:03:52 -0800 (PST) Received: by mail-yw0-x229.google.com with SMTP id i145so89908034ywg.2 for ; Sat, 26 Nov 2016 18:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=rM3FakRNcgIs9eGVaCt4dA4D04reu1N1xX3gdxxepQw=; b=sNvuyk84EpBZ4/ZQd4VhmMBQ3MzAQHbhLYs72oKLL4dWp9lG2akkWx+fBdLkEUgUYi P8ZwpUZ++yq9TTfrYhGSzfugwM8OFoaC6eYfmj1Kxwol4FU7WzMfrrmDQIGbgHH+f8eR WL+39vOanjPI5avaIEP+KD7HTSi490qfimZoX9JSEN0iBMUMAJAWI+0KFwlVzYJ5ONIS 2muAOCGh08wv9VE0DL3FGwV3f7dHGBClo1RXhFlDkyiU/eSfz8xj4YlR5aSLvsHoUAKS HFbcQFhSQBE5tEZwx1rdH0SQWCMjm9uDTgXYV6ZjW32KdKh/vwNOfuwLeGsvy+msO1rG UtnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=rM3FakRNcgIs9eGVaCt4dA4D04reu1N1xX3gdxxepQw=; b=YbtU10Pt4aYEmfSbibUhZBgQg+5DX6HJ69k5KyIRs04OJn755yHSZeM/MOSLm0k2Lu 1oHY9l45+ibGLla9tbIKivNkshKumD0Q/FO8oxz57Zv6sQCNMvpKqGQCMN3xzq+ntnBN SyLnPc+9Cz0hZFm5Z6Fd7rrfjo19sAn6Nx+EU59FdBDzfyFtbRGswx54UhzFeDiXpoBo BQxc2/5stPh94HOJDvniWceHb7kUDY6Lt1iW3wQe8Fhnr4nSUjauDgLnZzhO89gUKTcS uQsVNVwZiLg5Inye676wwAg4/M6PXnvklwxIbnv0Ovxchhziw0GCDKjAZHdl+A4RjBvg novQ== X-Gm-Message-State: AKaTC00pwCqcP0lFSduVY1IaxpBm/kLrsFkxwlQpNIwRzQrYbsAJtDj8SDUttSshJefQYqp64gvurnzxxE0TiQ== X-Received: by 10.13.195.5 with SMTP id f5mr20554841ywd.354.1480212231036; Sat, 26 Nov 2016 18:03:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Sat, 26 Nov 2016 18:03:10 -0800 (PST) In-Reply-To: <20161127015437.kfcwpemeppg3yw7h@pinky.local> References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> From: Eric Rescorla Date: Sat, 26 Nov 2016 18:03:10 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114d5fd639521e05423ec4b6 Archived-At: Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 27 Nov 2016 02:03:53 -0000 --001a114d5fd639521e05423ec4b6 Content-Type: text/plain; charset=UTF-8 TLS already contains a certificate caching mechanism ( https://tools.ietf.org/html/rfc7924). A more general scheme looks like it ought to perform better against new sites, though I've also heard some questions about whether the additional complexity tradeoff is worth it. If someone wanted to write a certificate compression draft for TLS, this certainly is something that would be worth examining. I don't see any reason we would need to limit/tie it to TLS 1.3 however. -Ekr On Sat, Nov 26, 2016 at 5:54 PM, Alessandro Ghedini wrote: > Hello, > > not sure if this has been discussed before (apologies if it has). > > QUIC mandates that certificate chains be gzip compressed in order to > reduce the > amount of bytes transmitted during full handshake. > > The QUIC crypto document says: > > Any remaining certificates are gzip compressed with a pre-shared > dictionary > that consists of the certificates specified by either of the first two > methods, and a block of common strings from certificates taken from the > Alexa top 5000. > > https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_ > L2f5LTaDUDwvZ5L6g/edit#heading=h.fgd4sj5avil0 > > Has anyone though about including something like that in TLS 1.3? > > Given that certificates usually take up most of the bytes exchanged during > a > full handshake it seems this could be useful, but I don't know if in > practice > the benefits are worth the added complexity. Thoughts? > > Cheers > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114d5fd639521e05423ec4b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
TLS already contains a certificate caching mechanism (https://tools.ietf.org/html/rfc= 7924).

A more general scheme looks like it ought to = perform better against new sites, though I've
also heard some= questions about whether the additional complexity tradeoff is worth it.
If someone wanted to write a certificate compression draft for TLS,= this certainly is something
that would be worth examining. I don= 't see any reason we would need to limit/tie it to TLS 1.3
ho= wever.

-Ekr

On Sat, Nov 26, 2016 at 5:54 P= M, Alessandro Ghedini <alessandro@ghedini.me> wrote:
=
Hello,

not sure if this has been discussed before (apologies if it has).

QUIC mandates that certificate chains be gzip compressed in order to reduce= the
amount of bytes transmitted during full handshake.

The QUIC crypto document says:

=C2=A0 Any remaining certificates are gzip compressed with a pre-shared dic= tionary
=C2=A0 that consists of the certificates specified by either of the first t= wo
=C2=A0 methods, and a block of common strings from certificates taken from = the
=C2=A0 Alexa top 5000.

https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45= IblHd_L2f5LTaDUDwvZ5L6g/edit#heading=3Dh.fgd4sj5avil0

Has anyone though about including something like that in TLS 1.3?

Given that certificates usually take up most of the bytes exchanged during = a
full handshake it seems this could be useful, but I don't know if in pr= actice
the benefits are worth the added complexity. Thoughts?

Cheers

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114d5fd639521e05423ec4b6-- From nobody Sat Nov 26 20:42:26 2016 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 387941294B6 for ; Sat, 26 Nov 2016 20:42:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] 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 iKantm_yP5PA for ; Sat, 26 Nov 2016 20:42:22 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 7BAF2129469 for ; Sat, 26 Nov 2016 20:42:22 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id n6so96335859qtd.1 for ; Sat, 26 Nov 2016 20:42:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bfaFqaGsQeKvtOUcB5hTxK7qsgbDIm+lBLHcSe5BeUk=; b=ECO0L/tl0Z4qiQgbmx4gBLpH7lAdv/U89PQr5mYqP3mqkNnxhAXBTOUHe/QnmqBmAh roNGJ2IYS4d76zJk4VqvNiKDC8Q0IDlNI6dx95A0bsrdzrGUsWFgoGpIIPz37heMoceb tGr5XcfiwYmrNpoe/k/cz4q8uoVxaQ9PhCz24gJmrJ+Xlo5gYVPjxlkEuk/QZcIgnEq4 hNzb02eJdXOGzbHRt/61CfMZkpIsdy7g5vU0RAQucTb/ABu4EugrD0DdPO8/PVFTk531 X4vSvMXgsn1NkJ2LmkHFV+g9ziVI/MHbklC/USAfk5xOblOz6Ao/8EvziQRnHDSra0ab v6rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bfaFqaGsQeKvtOUcB5hTxK7qsgbDIm+lBLHcSe5BeUk=; b=h6oSr3b9TZBIFEdHCkVEkDB7druPGhUY9jVOPjvDeErGLbgvTLqdpobJNhk9RayNkm Az/THXD3HUK7UCUfXLvLSKBbrwyItE3rxjqYo3fG+56/2E4tQf9kbVjQUF8BZtwpv3lO hW+Wj83nx6UyV1B0aLfxLY8g7COIJEJa5kejVN2WoUC0m/QoBzr34sREpgLh6T7A/Z/r anAImHsAj+mYKP0+3e1iqxZe9tPkh2RcYyrf4CaThlEKRiwQfz5likPSTgk5Qim/8HaW samUxwrwyo2b/SZsFQuK/3CqYxMca7i3p75BkGPvB6XimMY3cbxmvrBVBq6139csBCxv u1BA== X-Gm-Message-State: AKaTC03+qZP6efTPPUQIooxRCsY46AXTOoY2NlrJd/5c9OcIC4zJlBPX8sS2wqBmrdYzPUUr2gfIL6L3PVJ91d+8 X-Received: by 10.237.53.56 with SMTP id a53mr13033928qte.85.1480221741196; Sat, 26 Nov 2016 20:42:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.55.157.11 with HTTP; Sat, 26 Nov 2016 20:42:20 -0800 (PST) In-Reply-To: References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> From: Victor Vasiliev Date: Sat, 26 Nov 2016 23:42:20 -0500 Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=001a11c0302a130324054240fb2e Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 27 Nov 2016 04:42:24 -0000 --001a11c0302a130324054240fb2e Content-Type: text/plain; charset=UTF-8 I am currently trying to figure out how much of QUIC certificate compression can be adapted to work with TLS. I will submit a draft as soon as I have a working prototype. -- Victor. On Sat, Nov 26, 2016 at 9:03 PM, Eric Rescorla wrote: > TLS already contains a certificate caching mechanism ( > https://tools.ietf.org/html/rfc7924). > > A more general scheme looks like it ought to perform better against new > sites, though I've > also heard some questions about whether the additional complexity tradeoff > is worth it. > If someone wanted to write a certificate compression draft for TLS, this > certainly is something > that would be worth examining. I don't see any reason we would need to > limit/tie it to TLS 1.3 > however. > > -Ekr > > On Sat, Nov 26, 2016 at 5:54 PM, Alessandro Ghedini > wrote: > >> Hello, >> >> not sure if this has been discussed before (apologies if it has). >> >> QUIC mandates that certificate chains be gzip compressed in order to >> reduce the >> amount of bytes transmitted during full handshake. >> >> The QUIC crypto document says: >> >> Any remaining certificates are gzip compressed with a pre-shared >> dictionary >> that consists of the certificates specified by either of the first two >> methods, and a block of common strings from certificates taken from the >> Alexa top 5000. >> >> https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH >> d_L2f5LTaDUDwvZ5L6g/edit#heading=h.fgd4sj5avil0 >> >> Has anyone though about including something like that in TLS 1.3? >> >> Given that certificates usually take up most of the bytes exchanged >> during a >> full handshake it seems this could be useful, but I don't know if in >> practice >> the benefits are worth the added complexity. Thoughts? >> >> Cheers >> >> _______________________________________________ >> 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 > > --001a11c0302a130324054240fb2e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I am currently trying to figure out how much of QUIC certi= ficate compression can be adapted to work with TLS.=C2=A0 I will submit a d= raft as soon as I have a working prototype.

=C2=A0 -- Vi= ctor.

= On Sat, Nov 26, 2016 at 9:03 PM, Eric Rescorla <ekr@rtfm.com> wro= te:
TLS already contains= a certificate caching mechanism (https://tools.ietf.org/html/rfc7924).
A more general scheme looks like it ought to perform better= against new sites, though I've
also heard some questions abo= ut whether the additional complexity tradeoff is worth it.
If som= eone wanted to write a certificate compression draft for TLS, this certainl= y is something
that would be worth examining. I don't see any= reason we would need to limit/tie it to TLS 1.3
however.

-Ekr

=
On Sat, Nov 26, 2016 = at 5:54 PM, Alessandro Ghedini <alessandro@ghedini.me> w= rote:
Hello,

not sure if this has been discussed before (apologies if it has).

QUIC mandates that certificate chains be gzip compressed in order to reduce= the
amount of bytes transmitted during full handshake.

The QUIC crypto document says:

=C2=A0 Any remaining certificates are gzip compressed with a pre-shared dic= tionary
=C2=A0 that consists of the certificates specified by either of the first t= wo
=C2=A0 methods, and a block of common strings from certificates taken from = the
=C2=A0 Alexa top 5000.

https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblH<= wbr>d_L2f5LTaDUDwvZ5L6g/edit#heading=3Dh.fgd4sj5avil0

Has anyone though about including something like that in TLS 1.3?

Given that certificates usually take up most of the bytes exchanged during = a
full handshake it seems this could be useful, but I don't know if in pr= actice
the benefits are worth the added complexity. Thoughts?

Cheers

_______________________________________________
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


--001a11c0302a130324054240fb2e-- From nobody Sun Nov 27 07:13:15 2016 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 8BDD1129458 for ; Sun, 27 Nov 2016 07:13:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.498 X-Spam-Level: X-Spam-Status: No, score=-3.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ghedini.me 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 HK9-ektcyq_o for ; Sun, 27 Nov 2016 07:13:11 -0800 (PST) Received: from marceline.ghedini.me (marceline.ghedini.me [151.236.26.30]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9957D1293D8 for ; Sun, 27 Nov 2016 07:13:11 -0800 (PST) Received: from localhost (82-69-45-54.dsl.in-addr.zen.co.uk [82.69.45.54]) by marceline.ghedini.me (Postfix) with ESMTPSA id D757A207CB; Sun, 27 Nov 2016 15:13:05 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=ghedini.me; s=mail; t=1480259585; bh=twAb1r6BaZisPNFRl+zJoF8Z6QtNSADlLJgGg7HxVfc=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=Gym5kxheU14lDYNw3IyGQVLat1DMzAizodF2AvK7T0j4zsjCShMISWisXGE0wG3I5 OCPL1zEGAADpqYt3mAmOuZpcCDhZ6/Tk/kfLGyCMYFdzLYKFaCXJ7XOhYV2dl+V9IV bmmUh9lQ1g7FPLnv+K8C+I9Y5FSrXa0bTGkvZopI= Date: Sun, 27 Nov 2016 15:13:04 +0000 From: Alessandro Ghedini To: Victor Vasiliev Message-ID: <20161127151304.gaqxot5wqcmcey7n@pinky.local> Mail-Followup-To: Victor Vasiliev , tls@ietf.org References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20161104 (1.7.1) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Sun, 27 Nov 2016 15:13:13 -0000 On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote: > I am currently trying to figure out how much of QUIC certificate > compression can be adapted to work with TLS. I will submit a draft as soon > as I have a working prototype. FWIW I too have started working on a prototype for gzip compressing certificates based on BoringSSL: https://github.com/ghedo/boringssl/tree/cert_compress It's not complete yet and I only implemented compression so far based on what Chromium does with QUIC. I also haven't really tested it yet (but at least it builds AFAICT :) ). I'd like to do some tests as well to measure the benefits of this (e.g. download certificates from CT logs and see how effective the compression is). I also started working on a draft for gzip compression of certificates at: https://github.com/ghedo/tls-certificate-compression Or that's the current scope anyway. Maybe it would also make sense to include the full QUIC certificate caching part, but I didn't want to duplicate RFC7924. My intention would be to use gzip-compressed certs on first connect, and then use RFC7924 for consecutive handshakes. The text is not complete and I haven't submitted it yet, though it would be nice if we could work on the same draft together, in order to avoid duplicating work (I can give you or anyone interested commit access to the repo). Cheers From nobody Sun Nov 27 12:20:05 2016 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 A143212953C for ; Sun, 27 Nov 2016 12:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 6nojCj8MLgZV for ; Sun, 27 Nov 2016 12:20:02 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB2B7129527 for ; Sun, 27 Nov 2016 12:20:01 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 9F691284EA9; Sun, 27 Nov 2016 20:20:00 +0000 (UTC) Date: Sun, 27 Nov 2016 20:20:00 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20161127202000.GA26244@mournblade.imrryr.org> References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> <20161127151304.gaqxot5wqcmcey7n@pinky.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161127151304.gaqxot5wqcmcey7n@pinky.local> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org 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: Sun, 27 Nov 2016 20:20:03 -0000 On Sun, Nov 27, 2016 at 03:13:04PM +0000, Alessandro Ghedini wrote: > On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote: > > I am currently trying to figure out how much of QUIC certificate > > compression can be adapted to work with TLS. I will submit a draft as soon > > as I have a working prototype. > > FWIW I too have started working on a prototype for gzip compressing certificates > based on BoringSSL: > https://github.com/ghedo/boringssl/tree/cert_compress > > It's not complete yet and I only implemented compression so far based on what > Chromium does with QUIC. I also haven't really tested it yet (but at least it > builds AFAICT :) ). > > I'd like to do some tests as well to measure the benefits of this (e.g. > download certificates from CT logs and see how effective the compression is). My concerned is that any packet size benefit from compressing certificates with gzip is likely not worth the CPU cost and attack surface of performing the compression and uncompression. FWIW, my long-standing practice is to not link the SSL library with zlib. I was doing this as a matter of hygiene, long before the various attacks on (application payload) compression were reported. -- Viktor. From nobody Sun Nov 27 17:46:42 2016 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 55D8A127076 for ; Sun, 27 Nov 2016 17:46:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.197 X-Spam-Level: X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 7MWPpRxNKW9v for ; Sun, 27 Nov 2016 17:46:38 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id DC0BF12947A for ; Sun, 27 Nov 2016 17:46:37 -0800 (PST) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 20B97433402; Mon, 28 Nov 2016 01:46:37 +0000 (GMT) Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 09947433401; Mon, 28 Nov 2016 01:46:37 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480297597; bh=B+YAWilAigSEmhA0xr8/V+HAj84k+GfWSoTlIro8820=; l=2333; h=To:References:Cc:From:Date:In-Reply-To:From; b=BdX8kpag22ASOe+sfkdYFs0TpZ9jqS45CZ22qxNpWHd4RZls2hvIAJmZ1xOvUrL4q +I+EUE/0MyL4Ue/WMadqVHupwWCcncS+ljd4GXczNgaeiMNDHSEsbhky5f80DeCBAg zyPjfs0eNHMkory4xPlvziegTGIi83QvraEgleKk= Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BD3E41FC90; Mon, 28 Nov 2016 01:46:36 +0000 (GMT) To: Judson Wilson , Nikos Mavrogiannopoulos References: <1479884799.2563.3.camel@redhat.com> <1479889806.2563.15.camel@redhat.com> <1479890461.2563.20.camel@redhat.com> From: Benjamin Kaduk Message-ID: <2d13cdf3-3596-332c-43ef-f3b16dc88798@akamai.com> Date: Sun, 27 Nov 2016 19:46:36 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------4238DFC16DB401E28774A741" Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] record layer limits of TLS1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 28 Nov 2016 01:46:40 -0000 This is a multi-part message in MIME format. --------------4238DFC16DB401E28774A741 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 11/23/2016 02:46 AM, Judson Wilson wrote: > I worry about the buffer sizes required on embedded devices. Hopefully > the other endpoint would be programmed to limit record sizes, but is > that something we want to rely on? This could be a parameter agreed > upon during the handshake, but that seems bad. > My understanding is that the original motivation (which admittedly preceded me) included putting a cap on the amount of data that an endpoint could be forced to buffer, yes. Also note the proposal to steal the high bit of the length field to indicate encrypted records, in the proposal to reclaim the three fixed bytes from the record header. (https://github.com/tlswg/tls13-spec/pull/762) -Ben --------------4238DFC16DB401E28774A741 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 11/23/2016 02:46 AM, Judson Wilson wrote:
I worry about the buffer sizes required on embedded devices. Hopefully the other endpoint would be programmed to limit record sizes, but is that something we want to rely on?  This could be a parameter agreed upon during the handshake, but that seems bad.


My understanding is that the original motivation (which admittedly preceded me) included putting a cap on the amount of data that an endpoint could be forced to buffer, yes.

Also note the proposal to steal the high bit of the length field to indicate encrypted records, in the proposal to reclaim the three fixed bytes from the record header. (https://github.com/tlswg/tls13-spec/pull/762)

-Ben
--------------4238DFC16DB401E28774A741-- From nobody Mon Nov 28 01:36:51 2016 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 6C6351297EE for ; Mon, 28 Nov 2016 01:36:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 zI-KXEENd9Qi for ; Mon, 28 Nov 2016 01:36:49 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C1511297F0 for ; Mon, 28 Nov 2016 01:36:49 -0800 (PST) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 2B42761B90; Mon, 28 Nov 2016 09:36:48 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.199]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAS9ajBQ012273 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 28 Nov 2016 04:36:47 -0500 Message-ID: <1480325805.2778.5.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Alessandro Ghedini , Victor Vasiliev Date: Mon, 28 Nov 2016 10:36:45 +0100 In-Reply-To: <20161127151304.gaqxot5wqcmcey7n@pinky.local> References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> <20161127151304.gaqxot5wqcmcey7n@pinky.local> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Mon, 28 Nov 2016 09:36:48 +0000 (UTC) Archived-At: Cc: tls@ietf.org Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 28 Nov 2016 09:36:50 -0000 On Sun, 2016-11-27 at 15:13 +0000, Alessandro Ghedini wrote: > On Sat, Nov 26, 2016 at 11:42:20PM -0500, Victor Vasiliev wrote: > > I am currently trying to figure out how much of QUIC certificate > > compression can be adapted to work with TLS.  I will submit a draft > > as soon > > as I have a working prototype. > > FWIW I too have started working on a prototype for gzip compressing > certificates > based on BoringSSL: > https://github.com/ghedo/boringssl/tree/cert_compress > > It's not complete yet and I only implemented compression so far based > on what > Chromium does with QUIC. I also haven't really tested it yet (but at > least it > builds AFAICT :) ). I guess one could use the certificate type negotiation mechanism from RFC7250 to negotiate a compressed certificate, instead of a normal one. That would require registering an ID at: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml > I'd like to do some tests as well to measure the benefits of this > (e.g. > download certificates from CT logs and see how effective the > compression is). > > I also started working on a draft for gzip compression of > certificates at: > https://github.com/ghedo/tls-certificate-compression Have you considered lz4 instead of zlib? regards, Nikos From nobody Mon Nov 28 08:54:06 2016 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 B2C83129EA5 for ; Mon, 28 Nov 2016 08:54:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 KntxJIjqhSpf for ; Mon, 28 Nov 2016 08:54:03 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 677DC129EA2 for ; Mon, 28 Nov 2016 08:54:03 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id C8ADC300AEF for ; Mon, 28 Nov 2016 11:43:45 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id ZKbaLE4kjolc for ; Mon, 28 Nov 2016 11:43:45 -0500 (EST) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 98F08300687 for ; Mon, 28 Nov 2016 11:43:44 -0500 (EST) From: Russ Housley Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Message-Id: <43DF7E42-E6D3-4E12-BDFE-0FEEBB738818@vigilsec.com> Date: Mon, 28 Nov 2016 11:53:44 -0500 To: IETF TLS Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [TLS] Merging pre_shared_key and psk_key_exchange_modes extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 28 Nov 2016 16:54:04 -0000 Only the client ever sends the "psk_key_exchange_modes=94 extension. In = fact, the server MUST NOT send a "psk_key_exchange_modes" extension. The "pre_shared_key=94 extension is already divided into the structures = used by the client and the server. Why not add the ke_modes to the = client part of the "pre_shared_key=94 extension? This would have the advantage that the ke_modes would be integrity = protected by the HMAC carried in the PskBinderEntry. If I am not missing something, then the following would be one way to = accomplish this change: enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; struct { opaque identity<0..2^16-1>; PskKeyExchangeMode ke_modes<1..255>; uint32 obfuscated_ticket_age; } PskIdentity; opaque PskBinderEntry<32..255>; struct { select (Handshake.msg_type) { case client_hello: PskIdentity identities<6..2^16-1>; PskBinderEntry binders<33..2^16-1>; case server_hello: uint16 selected_identity; }; } PreSharedKeyExtension; From nobody Mon Nov 28 09:03:43 2016 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 4D2CB129E9A for ; Mon, 28 Nov 2016 09:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 miHYeW4D8s-A for ; Mon, 28 Nov 2016 09:03:40 -0800 (PST) Received: from mail-yw0-x236.google.com (mail-yw0-x236.google.com [IPv6:2607:f8b0:4002:c05::236]) (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 41305129538 for ; Mon, 28 Nov 2016 09:03:40 -0800 (PST) Received: by mail-yw0-x236.google.com with SMTP id r204so120810503ywb.0 for ; Mon, 28 Nov 2016 09:03:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UDAnynr8kksra0b1mgU4PZ7UgLDHFcQZ4ZtDdTKQNrs=; b=fX2PNwU4ty5P0ZWowFWmlgSkrrHz+ZP+YuzWQU5/KQcK0iwnDVYwnktfmIrOgcRrdd iwrJPth6kMrXAiLd6SfJPcN47CCiRbyQfGuGctbxUYysd1xPKWWVvPxue4vCP/TEWG8d Hw2/UMZcVMpHfHJhbgjbSp7nW1RhekXowxzCxLNmkhgO6DGh5drpAifoNIZJAy/04Rqs ow8CORXjY36I+eG8vXvFdqeTf2+dgoQuePVgXVsLYhwd734JXjaL2O7/RinvgU5TJjTv zvjDb84S3zXTUo/bYWcKZeqwPJ4YiWdpIgmz3MAbmf8P/bIqxHreZyjcZJdlC7ilvCcQ hw3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UDAnynr8kksra0b1mgU4PZ7UgLDHFcQZ4ZtDdTKQNrs=; b=akRGHfMkkV/c3X7nen+PJZ0l9K24zye8GGaCAN39Fttih3k3WXnNT2GsKUnGvLXAqM +2iJ1RnuOsipccNM2FWcWgxIe5u1/HNRgxhVvngX8gz9dyonpYij/hoVU1bejcoUaMTO TpDgTXLr2w7WcRH7hc1wVY6FMU1sf7fRK+03vd9W56bYqxqdOh/RFjxW8p/EnuKzjCQW EY9aW9/AH/XbjrYmci/KQWeY1aUA4HI4p3HJuv9Tmippvzbn8MrvETwXqbHMSIimenGp zaL9QAvTXb6iJn3fqWExJM2/BskF7m38BKtvAn2BjL6GAuNXqdo/6S9BPdEl6hF5n1bE N34A== X-Gm-Message-State: AKaTC03aEbX7bGBZgou8DO0+pffk3GzGKIHNSuy5fLtXU9jg3/DfuNP17XZwkBysQT/xm7RXO0lsUXTvMYS+ig== X-Received: by 10.129.125.215 with SMTP id y206mr26591097ywc.234.1480352619449; Mon, 28 Nov 2016 09:03:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 28 Nov 2016 09:02:58 -0800 (PST) In-Reply-To: <43DF7E42-E6D3-4E12-BDFE-0FEEBB738818@vigilsec.com> References: <43DF7E42-E6D3-4E12-BDFE-0FEEBB738818@vigilsec.com> From: Eric Rescorla Date: Mon, 28 Nov 2016 12:02:58 -0500 Message-ID: To: Russ Housley Content-Type: multipart/alternative; boundary=001a11492dfa068ad705425f742f Archived-At: Cc: IETF TLS Subject: Re: [TLS] Merging pre_shared_key and psk_key_exchange_modes extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 28 Nov 2016 17:03:42 -0000 --001a11492dfa068ad705425f742f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Nov 28, 2016 at 11:53 AM, Russ Housley wrote= : > Only the client ever sends the "psk_key_exchange_modes=E2=80=9D extension= . In > fact, the server MUST NOT send a "psk_key_exchange_modes" extension. > > The "pre_shared_key=E2=80=9D extension is already divided into the struct= ures used > by the client and the server. Why not add the ke_modes to the client par= t > of the "pre_shared_key=E2=80=9D extension? > This version allows you to tell the server that you would support a specific set of modes (so it knows whether to send you a ticket or not) without the need to allow an empty PSK list (with the small side effect that you can check the minimum 1 requirement at the syntax level. This would have the advantage that the ke_modes would be integrity > protected by the HMAC carried in the PskBinderEntry. > It already is protected. -Ekr > > If I am not missing something, then the following would be one way to > accomplish this change: > > enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchangeMode; > > struct { > opaque identity<0..2^16-1>; > PskKeyExchangeMode ke_modes<1..255>; > uint32 obfuscated_ticket_age; > } PskIdentity; > > opaque PskBinderEntry<32..255>; > > struct { > select (Handshake.msg_type) { > case client_hello: > PskIdentity identities<6..2^16-1>; > PskBinderEntry binders<33..2^16-1>; > > case server_hello: > uint16 selected_identity; > }; > > } PreSharedKeyExtension; > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a11492dfa068ad705425f742f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Nov 28, 2016 at 11:53 AM, Russ Housley <housley@vigilsec.co= m> wrote:
Only the client e= ver sends the "psk_key_exchange_modes=E2=80=9D extension.=C2=A0 In fac= t, the server MUST NOT send a "psk_key_exchange_modes" extension.=

The "pre_shared_key=E2=80=9D extension is already divided into the str= uctures used by the client and the server.=C2=A0 Why not add the ke_modes t= o the client part of the "pre_shared_key=E2=80=9D extension?

This version allows you to tell the server that = you would support a specific set of modes (so it knows whether to send you = a ticket or not) without the need to allow an empty PSK list (with the smal= l side effect that you can check the minimum 1 requirement at the syntax le= vel.


This would have the advantage that the ke_modes would be integrity protecte= d by the HMAC carried in the PskBinderEntry.

It already is protected.

-Ekr
=C2= =A0

If I am not missing something, then the following would be one way to accom= plish this change:

=C2=A0 =C2=A0 =C2=A0 enum { psk_ke(0), psk_dhe_ke(1), (255) } PskKeyExchang= eMode;

=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 opaque identity<0..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PskKeyExchangeMode ke_modes<1..255>= ;;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint32 obfuscated_ticket_age;
=C2=A0 =C2=A0 =C2=A0 } PskIdentity;

=C2=A0 =C2=A0 =C2=A0 opaque PskBinderEntry<32..255>;

=C2=A0 =C2=A0 =C2=A0 struct {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 select (Handshake.msg_type) {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case client_hello:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PskIdentity = identities<6..2^16-1>;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PskBinderEnt= ry binders<33..2^16-1>;

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 case server_hello:
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 uint16 selec= ted_identity;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 };

=C2=A0 =C2=A0 =C2=A0 } PreSharedKeyExtension;

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a11492dfa068ad705425f742f-- From nobody Mon Nov 28 09:05:16 2016 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 365D9129EA5 for ; Mon, 28 Nov 2016 09:05:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.899 X-Spam-Level: X-Spam-Status: No, score=-101.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no 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 i1ehQgFRN8BE for ; Mon, 28 Nov 2016 09:05:13 -0800 (PST) Received: from mail.smeinc.net (mail.smeinc.net [209.135.209.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89320129538 for ; Mon, 28 Nov 2016 09:05:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.smeinc.net (Postfix) with ESMTP id 0E8E9300AF6 for ; Mon, 28 Nov 2016 11:54:56 -0500 (EST) X-Virus-Scanned: amavisd-new at mail.smeinc.net Received: from mail.smeinc.net ([127.0.0.1]) by localhost (mail.smeinc.net [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 2CnHvqFU8Xkq for ; Mon, 28 Nov 2016 11:54:55 -0500 (EST) Received: from [10.85.3.71] (wsip-98-172-24-238.dc.dc.cox.net [98.172.24.238]) by mail.smeinc.net (Postfix) with ESMTPSA id 3F6A2300687; Mon, 28 Nov 2016 11:54:52 -0500 (EST) Content-Type: multipart/alternative; boundary="Apple-Mail=_EF75FCB8-078D-40AC-B74A-79CF2A5BEF6C" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Russ Housley In-Reply-To: Date: Mon, 28 Nov 2016 12:05:09 -0500 Message-Id: <0BB38ADE-F19F-4E6A-95ED-FB12ED1D2730@vigilsec.com> References: <43DF7E42-E6D3-4E12-BDFE-0FEEBB738818@vigilsec.com> To: Eric Rescorla X-Mailer: Apple Mail (2.1878.6) Archived-At: Cc: IETF TLS Subject: Re: [TLS] Merging pre_shared_key and psk_key_exchange_modes extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 28 Nov 2016 17:05:15 -0000 --Apple-Mail=_EF75FCB8-078D-40AC-B74A-79CF2A5BEF6C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Eric: > On Mon, Nov 28, 2016 at 11:53 AM, Russ Housley = wrote: > Only the client ever sends the "psk_key_exchange_modes=94 extension. = In fact, the server MUST NOT send a "psk_key_exchange_modes" extension. >=20 > The "pre_shared_key=94 extension is already divided into the = structures used by the client and the server. Why not add the ke_modes = to the client part of the "pre_shared_key=94 extension? >=20 > This version allows you to tell the server that you would support a = specific set of modes (so it knows whether to send you a ticket or not) = without the need to allow an empty PSK list (with the small side effect = that you can check the minimum 1 requirement at the syntax level. I see. Thanks. Russ= --Apple-Mail=_EF75FCB8-078D-40AC-B74A-79CF2A5BEF6C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Eric:

On Mon, Nov 28, 2016 at 11:53 AM, Russ Housley <housley@vigilsec.com> wrote:
Only the client ever sends = the "psk_key_exchange_modes=94 extension.  In fact, the server MUST = NOT send a "psk_key_exchange_modes" extension.

The = "pre_shared_key=94 extension is already divided into the structures used = by the client and the server.  Why not add the ke_modes to the = client part of the "pre_shared_key=94 extension?

This version allows you to tell the = server that you would support a specific set of modes (so it knows = whether to send you a ticket or not) without the need to allow an empty = PSK list (with the small side effect that you can check the minimum 1 = requirement at the syntax level.

I see. =  Thanks.

Russ
= --Apple-Mail=_EF75FCB8-078D-40AC-B74A-79CF2A5BEF6C-- From nobody Mon Nov 28 11:32:09 2016 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 437EA12950B for ; Mon, 28 Nov 2016 11:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 Mg9GOVHwCeCY for ; Mon, 28 Nov 2016 11:32:01 -0800 (PST) Received: from mail-yw0-x22b.google.com (mail-yw0-x22b.google.com [IPv6:2607:f8b0:4002:c05::22b]) (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 B45291294F9 for ; Mon, 28 Nov 2016 11:32:00 -0800 (PST) Received: by mail-yw0-x22b.google.com with SMTP id i145so123703350ywg.2 for ; Mon, 28 Nov 2016 11:32:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=ziMFzbogM64GlgUIHRFsxvBuiTovOmQ23/4q2IMdPSo=; b=GJ9E+c7uhkIKGHYq+cNmTlVKRME9H/j9kSWxdxvha+l1eko5EArqOkkYUBrwGuYrfa YzYI9iYHGQg3qrFgjYGgfcK/gNnvpHqXeADwfkxj+BfaoiBygQHnqrt5A+XBebRLDkC1 tWdaWlAO1PbBC+vuB56TPCKfPxlc2JXj0WaI4ydc+cQcyo63Ka9hxYZJb+dKGVibDNaG PuiN5aXhjOzN+tAT6ntBLIMsthysG+nuLzM2Q34v6Q8/7rt2TRJszDIPf+0t4Iep1mxR x2g1HZ7wALZl4x5Ntnsf6Rzk7nFnYOKfBt4/tIgKn7RXFeDvIAMn41q0Ys1mB8QnbsPA SAUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ziMFzbogM64GlgUIHRFsxvBuiTovOmQ23/4q2IMdPSo=; b=WHlC5IQIDZQjT9eREpbCkSPXUk1KvbEtXb2V6PxtBL3yJiRNnEB8xHYDrdFRKBblPg ygAz762cAp+sofPQcEcOQrxdTKT6+EBbtpDFTSlmDN8kiWZouw2VajxAXkD7r4oMbzCc 8aFlQEhDYNMPAbBH7unnNBiL9ISVtF/JtC/baSLJwKwBPsvV2criMu8XB1GYJPH0F2jM XLxeGBY7zOVxi5eSo/w9aUthw7Gyb3mTXPiAVjydwf3NuhLi5Y3mFfEfZGFe/YNoB6Yk Xh57d5C1eaJ+k/bp+yDHswv1ZFdwPlhlPZqAwAdKgCf4eJwSjRUXtRNR8xh442YyXiWm Gb0w== X-Gm-Message-State: AKaTC009pZLA2k5o/FfiqaQY4w38FQuUmRwdR+Ad21AnMMxDIewEhPDCdyQDZDJBvMLuMo76+/Q8+vQ3kfoH0Q== X-Received: by 10.129.125.215 with SMTP id y206mr27169949ywc.234.1480361519811; Mon, 28 Nov 2016 11:31:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.159.141 with HTTP; Mon, 28 Nov 2016 11:31:19 -0800 (PST) From: Eric Rescorla Date: Mon, 28 Nov 2016 14:31:19 -0500 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11492dfa873bb205426186bc Archived-At: Subject: [TLS] Point validation (PR#763) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 28 Nov 2016 19:32:07 -0000 --001a11492dfa873bb205426186bc Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/763 Barring technical objections (e.g., this is incorrect), I intend to merge this PR requiring point validation on Wednesday. -Ekr --001a11492dfa873bb205426186bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
h= ttps://github.com/tlswg/tls13-spec/pull/763

Barr= ing technical objections (e.g., this is incorrect), I intend to merge this = PR requiring point validation on Wednesday.

-E= kr

--001a11492dfa873bb205426186bc-- From nobody Mon Nov 28 12:09:39 2016 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 B90C7129FAB for ; Mon, 28 Nov 2016 12:09:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mobileironinc.onmicrosoft.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 R3XeF3iRucvB for ; Mon, 28 Nov 2016 12:09:35 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0054.outbound.protection.outlook.com [104.47.36.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 957C0129FA4 for ; Mon, 28 Nov 2016 12:09:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mobileironinc.onmicrosoft.com; s=selector1-mobileiron-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N3sIBpQC19P9F1yZvKJxzUc4sWi8BGI4pboCtuA1vwE=; b=K9qAdCtqPImZnNzEq43JK31aseJtKsOSprk4IjFrW6KDXdnr9KKKO0clMrB+WZJn2SzyNyvo4ddveiws+pClOT8t1vg6jt6DGcWdz6Lkxv8FCJiOLlPJ1urodjBDCt0BtLQ2aW8jUIV1Fe69A1SKQ3J0tXkBP+c+2SBVyrclUqI= Received: from CY4PR10MB1734.namprd10.prod.outlook.com (10.172.69.9) by CY4PR10MB1736.namprd10.prod.outlook.com (10.172.69.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.747.13; Mon, 28 Nov 2016 20:09:33 +0000 Received: from CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) by CY4PR10MB1734.namprd10.prod.outlook.com ([10.172.69.9]) with mapi id 15.01.0747.015; Mon, 28 Nov 2016 20:09:34 +0000 From: Timothy Jackson To: Dan Brown , "tls@ietf.org" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFcI8bXCvpZ0kinF1LM7JA3cKDipymAgALvxwCABDsjAIAEi/mA Date: Mon, 28 Nov 2016 20:09:34 +0000 Message-ID: <93E7E12D-BD4F-46AE-A5A4-C344EE17FA3C@mobileiron.com> References: <201611221706.50692.davemgarrett@gmail.com> <810C31990B57ED40B2062BA10D43FBF501083213@XMB116CNC.rim.net> In-Reply-To: <810C31990B57ED40B2062BA10D43FBF501083213@XMB116CNC.rim.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tjackson@mobileiron.com; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [198.61.62.10] x-ms-office365-filtering-correlation-id: 6f05e79a-bb17-4e59-6fa0-08d417ca78b5 x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:CY4PR10MB1736; x-microsoft-exchange-diagnostics: 1; CY4PR10MB1736; 7:1+4OWRx7dWg5vV51hWHlSgEKp3gPQpYQLd0Imo9HjSHc9oL7Wqo3BfPoCOqb+d3grVCTNNMuEzSmhvr59pJFf+rYqMT+HowU9vqwOsmu9D8+rKk9moDvBaHd3DWBUwf/PLvKb671fcxplAIhd9Xtet+wIURuXC3Wfz4dzQ1Rekd+LQJ6cpZ6KkDkhR83BVobiGxT2s5ZZ5/g/TQ1n6/RuYnuWuL/vAYdRm8QUtgOZ1q3PFuhTYRyHv6qxRdryW+coO8ROXlKrdwifU55Rs0zppEc95qJKIObFqxlaEdO6/6bwDDiv7WZMDOvGVAzUjPNyH2WiDLk8pjRPy2L6a01S9lp9w536ivHP+LHCO6fMSt/PVUXXA+aT/WDuO6sNO3+uMtU2EHH5A7XmImWnLLqY9FkWwRDeCEWHV5LXXg6mNvQob2eJdLQEVd2PSAASc6iNtawJrZL61Rsa8zHlV6z3Q== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(788757137089)(100405760836317); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6060326)(6040361)(6045199)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6061324)(6041248)(20161123560025)(20161123555025)(20161123564025)(20161123562025)(6072148); SRVR:CY4PR10MB1736; BCL:0; PCL:0; RULEID:; SRVR:CY4PR10MB1736; x-forefront-prvs: 01401330D1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(189002)(24454002)(199003)(13464003)(377454003)(2950100002)(6116002)(305945005)(107886002)(5001770100001)(92566002)(2900100001)(97736004)(36756003)(189998001)(7846002)(102836003)(3846002)(82746002)(66066001)(106116001)(106356001)(7736002)(99286002)(5660300001)(83716003)(105586002)(39400400001)(54356999)(229853002)(76176999)(86362001)(8676002)(81166006)(33656002)(575784001)(68736007)(8936002)(81156014)(6486002)(77096006)(39450400002)(50986999)(38730400001)(101416001)(93886004)(2501003)(3660700001)(2906002)(3280700002)(39380400001)(39410400001)(122556002)(6506003)(6512003)(104396002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR10MB1736; H:CY4PR10MB1734.namprd10.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: mobileiron.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <8E61D4CF3D47844DB9D14C58F86341BB@namprd10.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: mobileiron.com X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2016 20:09:34.0530 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1736 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Mon, 28 Nov 2016 20:09:38 -0000 QXQgdGhpcyBwb2ludCwgbXkgcGVyc29uYWwgb3BpbmlvbiBpcyB0byBtb3ZlIG9uIGZyb20gVExT IDEuMyB0byBlaXRoZXIgVExTIDQvNC4wIG9yIFRMUyAyMDE3Lg0KDQpBZnRlciAxNSB5ZWFycywg ZXZlcnlvbmUgYnV0IHVzIHN0aWxsIGNhbGxzIGl0IFNTTC4gV2UgbmVlZCB0byBhZG1pdCB0aGF0 IHdlIGxvc3QgdGhlIG1hcmtldGluZyBiYXR0bGUgYW5kIHBsYW4gZm9yIGEgd29ybGQgd2hlcmUg ZXZlcnlvbmUgY2FsbHMg4oCcVExTIFjigJ0g4oCcU1NMIFjigJ0uIEV2ZW4g4oCcbmV34oCdIGlt cGxlbWVudGF0aW9ucyBjYWxsIHRoZW1zZWx2ZXMg4oCcTGlicmVTU0zigJ0gYW5kIOKAnEJvcmlu Z1NTTOKAnSByYXRoZXIgdGhhbiDigJxMaWJyZVRMU+KAnSBvciDigJxCb3JpbmdUTFPigJ0uDQoN CkFzIFNTTCBpcyByZW1vdmVkIGZyb20gcHJvZHVjdHMsIHdl4oCZcmUgbGlrZWx5IHRvIGdldCBt b3JlIGFuZCBtb3JlIHF1ZXN0aW9ucyDigJx3aHkgYW0gSSB1c2luZyBTU0wgMS4yLCB3aGVuIEkg dGhvdWdodCBTU0wgMyB3YXMgYnJva2VuP+KAnSBUaGlzIGlzIGEgKmxlZ2l0aW1hdGUqIHF1ZXN0 aW9uIGJ5IGEgdXNlciB3aG8gaXMgZWR1Y2F0ZWQgZW5vdWdoIHRvIGtub3cgdGhhdCDigJxTU0wg MyBpcyBiYWTigJ0gYnV0IGhhcyBtb3JlIGltcG9ydGFudCB0aGluZ3MgdG8gcmVtZW1iZXIgdGhh biB0aGUgZGlzdGluY3Rpb24gYmV0d2VlbiBTU0wgYW5kIFRMUy4gQXMgb3RoZXJzIGhhdmUgbm90 ZWQsIFRMUyA0IGZpeGVzIHRoaXMgd2hlbiB1c2VycyBjYWxsIGl0IFNTTCA0LCB3aGljaCB0aGV5 IGRlZmluaXRlbHkgd2lsbC4NCg0KVGltDQoNCk9uIDExLzI1LzE2LCA2OjQzIEFNLCAiVExTIG9u IGJlaGFsZiBvZiBEYW4gQnJvd24iIDx0bHMtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yg ZGFuaWJyb3duQGJsYWNrYmVycnkuY29tPiB3cm90ZToNCg0KICAgIEkgZG9uJ3Qgb3Bwb3NlIGFu eSBvZiB0aGUgNCBnaXZlbiBvcHRpb25zLCBidXQgSSBzbGlnaHRseSBwcmVmZXIgVExTIDIuMCwg aXQgc2VlbXMgc2ltcGxlIGFuZCBjbGVhci4gIA0KICAgIA0KICAgIEluIG15IG9waW5pb24sIHRo ZSB3aG9sZSBTU0wgdnMgVExTIGNvbmZ1c2lvbiBuZWVkcyBiZXR0ZXIgZWR1Y2F0aW9uIHRvIGNv bmZyb250LCB2ZXJzaW9uIG51bWJlcnMgKGV2ZW4gZGF0ZXMpIGFsb25lIG1pZ2h0IG5vdCBiZSBl bm91Z2guICBSZW5hbWluZyAqU1NMIHByb2R1Y3RzIHRvICpUTFMgc2hvdWxkIGhlbHAuICBBdm9p ZGluZyAiU1NML1RMUyIgbWlnaHQgaGVscC4NCiAgICANCiAgICBTaW5jZSBvdGhlcnMgaGF2ZSBw cm9wb3NlZCBuZXcgb3B0aW9ucywgaG93IGFib3V0IFRMUyAyLjAxNz8gVXNpbmcgdGhlIGRhdGUg aGFzIGJlbmVmaXRzLCBidXQgdGhlIGFjdHVhbCBjcnlwdG8gY2hhbmdlcyBhcmUgbXVjaCBtb3Jl IGltcG9ydGFudCwgc28gdGhlIGRlY2ltYWwgbWFrZXMgdGhhdCBwb2ludC4gIEFuIG9sZCBjcnlw dG8gcHJpbmNpcGxlIGlzIHRoYXQgb2xkZXIgaXMgYmV0dGVyIChhbW9uZyBlcXVhbGx5IHVuYnJv a2VuIG9wdGlvbnMpIC0tIGJ1dCBuYW1pbmcgbmV3IHN0dWZmIGlzIGp1c3Qgbm90IGVub3VnaCB0 byByaWQgdXMgb2YgYnJva2VuIG9sZCBzdHVmZiwgc28gcHV0dGluZyBkYXRlcyBpbiBuYW1lcyBt aWdodCBub3QgdW5kZXJtaW5lIHRoaXMgcHJpbmNpcGxlLiAgRm9yIGZ1dHVyZSBuYW1pbmcsIG9u IG1pbm9yIGNoYW5nZXMgKG9yIGV2ZW4gcHJlLXNjaGVkdWxlZCByZXZpZXdzIHdpdGggbm8gY2hh bmdlcyksIHVwZGF0ZSB0aGUgZGF0ZSBwYXJ0LCBvbiBtYWpvciBjaGFuZ2VzLCBzdGFydCBmcm9t IHNjcmF0Y2ggKGFzIGluIDMuMjAyNCwgb3IgZXZlbiB1c2UgZGlmZmVyZW50IGxldHRlcnMgLi4u ICkuICANCiAgICANCiAgICBCeSB0aGUgd2F5LCBJJ20gc29ycnkgaWYgbXkgb3BpbmlvbiBkaXZl cmdlcyBmcm9tIHRoZSBjdXJyZW50bHkgZm9ybWluZyBjb25zZW5zdXMuDQogICAgDQogICAgSnVz dCBteSAkMC4wMi4NCiAgICAgIA0KICAgIERhbg0KICAgIA0KICAgIFBTIEp1c3QgdG8gYmUgY2xl YXIsIGlmIHZvdGVzIGFyZSB0byBiZSB0YWxsaWVkLCBteSB2b3RlIG9uIHRoaXMgaXNzdWUgc2hv dWxkIGJlIHdlaWdodGVkIHF1aXRlIGxvdyAoaS5lLiAwLCB1bmxlc3Mgb3RoZXIgdm90ZXMgYXJl IHdlaWdodGVkIGxvdyB0b28sIGFuZCBzb21lIGtpbmQgb2YgdGllLWJyZWFrZXIgaXMgbmVlZGVk KSwgZm9yIGF0IGxlYXN0IHRocmVlIHJlYXNvbnM6IEkgaGF2ZSBub3QgZm9sbG93ZWQgdGhlIFRM UyAxLjMvMi4wIHNwZWMgY2xvc2VseSAoaS5lLiwgSSBoYWQgbm8gcGFydCBpbiBidWlsZGluZyB0 aGUgc2hlZCk7IEkgaGF2ZSBuZWFybHkgemVybyBleHBlcmllbmNlIGRlYWxpbmcgd2l0aCB1c2Vy IGludGVycHJldGF0aW9uIChpLmUuIG1hcmtldGluZykgb2YgcHJvdG9jb2wgbmFtZXM7IG15IHBy ZWZlcmVuY2UgaXMgd2Vhay4gKEVub3VnaCB0byBkZXNlcnZlIGEgbmVnYXRpdmUgd2VpZ2h0LCBp ZiB0aGF0IHdlcmUgbm90IGNoZWF0YWJsZTspDQogICAgDQogICAgUFBTIEkndmUgc2FpZCBiZWZv cmUgdGhhdCBJIHByZWZlciBUTEMocnlwdG8pIHRvIFRMUyhlY3VyaXR5KSwgYnV0IHRoYXQncyB1 bmxpa2VseSB0byBmbHksIGFuZCBpdCBtYXkgYmUgb2theSB0byBncmFuZGZhdGhlciB0aGlzIHRy YWRpdGlvbi4gIChJIGhvcGUgbmFtZXMgb2YgZnV0dXJlIGNyeXB0byBwcm90b2NvbHMgKHRoYXQg VExTIFdHIG1pZ2h0IHdvcmsgb24pIGNhbiBiZSBtb3JlIHNwZWNpZmljIGFuZCByZWFsaXN0aWMu KQ0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTogVExTIFtt YWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBEYXZlIEdhcnJldHQNCiAg ICBTZW50OiBUdWVzZGF5LCBOb3ZlbWJlciAyMiwgMjAxNiA1OjA3IFBNDQogICAgVG86IHRsc0Bp ZXRmLm9yZw0KICAgIFN1YmplY3Q6IFJlOiBbVExTXSBDb25maXJtaW5nIGNvbnNlbnN1czogVExT MS4zLT5UTFMqDQogICAgDQogICAgKHJlcGxpZXMgdG8gYSBidW5jaCBvZiBpZGVhcyBpbiB0aGlz IHRocmVhZCkNCiAgICANCiAgICBBcyB0aGUgcGVyc29uIHdobyBsaXQgdGhlIG1hdGNoIHVuZGVy IHRoaXMgbGF0ZXN0IGJpa2VzaGVkIGRlYmF0ZSwgcGVyc29uYWxseSwgSSBkb24ndCBzZWUgYSBz dHJvbmcgY29uc2Vuc3VzIGJ1aWxkaW5nIGhlcmUuIExlYXZpbmcgdGhlIGJpa2VzaGVkIHVucGFp bnRlZCBzZWVtcyBsaWtlIHRoZSBvcHRpb24gd2UncmUgaGVhZGVkIGZvciwgYXQgdGhpcyByYXRl LiBJJ20gZmluZSB3aXRoIFRMUyAxLjMgaWYgdGhhdCdzIHRoZSByZXN1bHQgaGVyZS4NCiAgICAN CiAgICBUaGF0IHNhaWQsIEkgdGhpbmsgSSd2ZSBiZWVuIHNvbWV3aGF0IHN3YXllZCB0byB0aGUg VExTIDQgY2FtcCB3aXRoIHRoZSAiZm91cnRoIHZlcnNpb24gb2YgVExTIiBtZXNzYWdlLiBJdCBt YWtlcyBhIGtpbmQgb2YgbWVzc3kgc2Vuc2UgdGhhdCdzIGtpbmQgb2YgZml0dGluZyBmb3IgVExT LiBJJ20gbm8gbG9uZ2VyIGFnYWluc3QgaXQuDQogICAgDQogICAgSSd2ZSBhbHNvIHN1Z2dlc3Rl ZCBoaWdobGlnaHRpbmcgdGhlIHllYXIgaW4gdGhlIHBhc3QsIGJ1dCBvbmx5IGluIHRoZSBjb250 ZXh0IG9mIHRoZSB0aXRsZSBhbmQgbWVzc2FnaW5nLCBub3QgYWN0dWFsbHkgcmVwbGFjaW5nIHRo ZSB2ZXJzaW9uIG51bWJlciBpdHNlbGYuIEknZCBiZSBvayB3aXRoIFRMUyAxLjMtMjAxNyAob3Ig c29tZXRoaW5nKSwgbm90IGRvaW5nIGEgZmluZC9yZXBsYWNlIG9mIDEuMyBhbmQgY2hhbmdpbmcg aXQgdG8gMjAxNywgd2hvbGVzYWxlLiBUaGF0IGp1c3QgZmVlbHMgZXZlbiBtb3JlIGNvbmZ1c2lu Zy4NCiAgICANCiAgICBMYXN0bHksIEkgYW0gdmVoZW1lbnRseSBhZ2FpbnN0IHRoZSBzdWdnZXN0 aW9uIG9mIGRpdGNoaW5nIHRoZSBUTFMgbmFtZSBpbiBmYXZvciBvZiBTU0wgYWdhaW4sIGFzIHdh cyBhbHNvIGJyb3VnaHQgdXAgaW4gdGhpcyB0aHJlYWQuIFNTTCBpcyBkZWFkIGFuZCBpbnNlY3Vy ZSwgYW5kIHRoYXQgbWVzc2FnZSBuZWVkcyB0byBzdGF5LiBXZSBuZWVkIHRvIGdldCBwZW9wbGUg dG8gc3RvcCBjb25mbGF0aW5nIHRoZSB0d28gYW5kIG1ha2luZyB0aGlzIHdvcnNlLCBub3QgYWNj ZXB0aW5nIGl0Lg0KICAgIA0KICAgIA0KICAgIERhdmUNCiAgICANCiAgICANCiAgICBPbiBTdW5k YXksIE5vdmVtYmVyIDIwLCAyMDE2IDA4OjE2OjA3IHBtIEVyaWMgUmVzY29ybGEgd3JvdGU6DQog ICAgPiBJIG1pbGRseSBwcmVmZXIgVExTIDEuMyB0byBUTFMgMiBhbmQgVExTIDQgKElmIHdlJ3Jl IGdvaW5nIHRvIHJldiB0aGUgDQogICAgPiBtYWpvciB2ZXJzaW9uIG51bWJlciB3ZSBzaG91bGQg YWJhbmRvbiB0aGUgbWlub3Igb25lKS4NCiAgICA+IFRMUyAyMDE3IHN0cmlrZXMgbWUgYXMgcXVp dGUgYmFkOyB3ZSdyZSBjZXJ0YWlubHkgbm90IHBsYW5uaW5nIHRvIGRvIGEgDQogICAgPiBUTFMg MjAxOC4gSSBhbSBzdHJvbmdseSBvcHBvc2VkIHRvIFRMUyAyMDE3Lg0KICAgID4gDQogICAgPiAt RWtyDQogICAgPiANCiAgICA+IA0KICAgID4gT24gRnJpLCBOb3YgMTgsIDIwMTYgYXQgMTE6MTIg QU0sIFNlYW4gVHVybmVyIDxzZWFuQHNuM3JkLmNvbT4gd3JvdGU6DQogICAgPiANCiAgICA+ID4g QXQgSUVURiA5NywgdGhlIGNoYWlycyBsZWFkIGEgZGlzY3Vzc2lvbiB0byByZXNvbHZlIHdoZXRo ZXIgdGhlIFdHIA0KICAgID4gPiBzaG91bGQgcmVicmFuZCBUTFMxLjMgdG8gc29tZXRoaW5nIGVs c2UuICBTbGlkZXMgY2FuIGJlIGZvdW5kIEANCiAgICA+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfcHJvY2VlZGluZ3Nf OTdfc2xpZGVzX3NsaWRlcy0yRCZkPUR3SUNBZyZjPU4wVXJqMjY5MXdfR19STWNJZDhCRk8yNTVK aHdZMW1VRzltUTR3Q3NkZzQmcj1OZFhBQ3FTQ3FuaWMydlhGajJzQjF3cUVPVmFMSjlYZ2V6RmE0 aG1KQW1BJm09YVZxZ1BFa1N0bk84d2xTZUhSU0dka3VxWVVISG9uT2FSbC1vSDVMMk4yQSZzPTZ5 SkdpTkd4Mm5BUHNtN0FhWl9HN0w1Wi1rMGZvcXJuZWhIY3duVTVNaUEmZT0gDQogICAgPiA+IDk3 LXRscy1yZWJyYW5kaW5nLWFrYS1wcjYxMi0wMS5wZGYuDQogICAgPiA+DQogICAgPiA+IFRoZSBj b25zZW5zdXMgaW4gdGhlIHJvb20gd2FzIHRvIGxlYXZlIGl0IGFzIGlzLCBpLmUuLCBUTFMxLjMs IGFuZCANCiAgICA+ID4gdG8gbm90IHJlYnJhbmQgaXQgdG8gVExTIDIuMCwgVExTIDIsIG9yIFRM UyA0LiAgV2UgbmVlZCB0byBjb25maXJtIA0KICAgID4gPiB0aGlzIGRlY2lzaW9uIG9uIHRoZSBs aXN0IHNvIHBsZWFzZSBsZXQgdGhlIGxpc3Qga25vdyB5b3VyIHRvcCBjaG9pY2UgYmV0d2VlbjoN CiAgICA+ID4NCiAgICA+ID4gLSBMZWF2ZSBpdCBUTFMgMS4zDQogICAgPiA+IC0gUmVicmFuZCBU TFMgMi4wDQogICAgPiA+IC0gUmVicmFuZCBUTFMgMg0KICAgID4gPiAtIFJlYnJhbmQgVExTIDQN CiAgICA+ID4NCiAgICA+ID4gYnkgMiBEZWNlbWJlciAyMDE2Lg0KICAgIA0KICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgVExTIG1haWxpbmcg bGlzdA0KICAgIFRMU0BpZXRmLm9yZw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fdGxz JmQ9RHdJQ0FnJmM9TjBVcmoyNjkxd19HX1JNY0lkOEJGTzI1NUpod1kxbVVHOW1RNHdDc2RnNCZy PU5kWEFDcVNDcW5pYzJ2WEZqMnNCMXdxRU9WYUxKOVhnZXpGYTRobUpBbUEmbT1hVnFnUEVrU3Ru Tzh3bFNlSFJTR2RrdXFZVUhIb25PYVJsLW9INUwyTjJBJnM9b3FCai1vTnZweERkSF9xYUNDRHU3 NW96eW5jc0lYNGxZY0JYSGhIVWVjSSZlPSANCiAgICANCiAgICBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIFRMUyBtYWlsaW5nIGxpc3QNCiAgICBU TFNAaWV0Zi5vcmcNCiAgICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX3RscyZkPUR3SUNBZyZj PU4wVXJqMjY5MXdfR19STWNJZDhCRk8yNTVKaHdZMW1VRzltUTR3Q3NkZzQmcj1OZFhBQ3FTQ3Fu aWMydlhGajJzQjF3cUVPVmFMSjlYZ2V6RmE0aG1KQW1BJm09YVZxZ1BFa1N0bk84d2xTZUhSU0dk a3VxWVVISG9uT2FSbC1vSDVMMk4yQSZzPW9xQmotb052cHhEZEhfcWFDQ0R1NzVvenluY3NJWDRs WWNCWEhoSFVlY0kmZT0gDQogICAgDQoNCg== From nobody Tue Nov 29 04:58:30 2016 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 843EB1298C8 for ; Tue, 29 Nov 2016 04:58:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 UdQGNNZfkvnV for ; Tue, 29 Nov 2016 04:58:26 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B902E12996C for ; Tue, 29 Nov 2016 04:56:46 -0800 (PST) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 031DD3D943; Tue, 29 Nov 2016 12:56:46 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uATCui8D023671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Nov 2016 07:56:45 -0500 From: Hubert Kario To: tls@ietf.org Date: Tue, 29 Nov 2016 13:56:43 +0100 Message-ID: <38962934.NWKWaTxzK0@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.8-200.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: <20161127015437.kfcwpemeppg3yw7h@pinky.local> References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1725826.g29Ucdy8O6"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 29 Nov 2016 12:56:46 +0000 (UTC) Archived-At: Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Nov 2016 12:58:28 -0000 --nextPart1725826.g29Ucdy8O6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Sunday, 27 November 2016 01:54:37 CET Alessandro Ghedini wrote: > Hello, >=20 > not sure if this has been discussed before (apologies if it has). >=20 > QUIC mandates that certificate chains be gzip compressed in order to redu= ce > the amount of bytes transmitted during full handshake. >=20 > The QUIC crypto document says: >=20 > Any remaining certificates are gzip compressed with a pre-shared > dictionary that consists of the certificates specified by either of the > first two methods, and a block of common strings from certificates taken > from the Alexa top 5000. >=20 > https://docs.google.com/document/d/1g5nIXAIkN_Y-7XJW5K45IblHd_L2f5LTaDUDw= vZ5 > L6g/edit#heading=3Dh.fgd4sj5avil0 >=20 > Has anyone though about including something like that in TLS 1.3? >=20 > Given that certificates usually take up most of the bytes exchanged durin= g a > full handshake it seems this could be useful, but I don't know if in > practice the benefits are worth the added complexity. Thoughts? Decompressing completely untrusted and unverified data directly in the=20 security library? No, I don't think we need more complex code in TLS implementations. =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart1725826.g29Ucdy8O6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYPXsLAAoJEJKo0bgB0vX1wbwP/Arz0eA5xyduoVDkoejNOCTy YRC0sQwZIOcnzbI4zbIPBOAaWv3AawPRa08W96vpCPW8H4ydlqEkEoUWTUh0KHJO DJLImFoHPTn/VUNZNIUcJWZYLrDsvdVrRikbZL7mHrPQd5ZwozCJr9UpaNQhC0KL eseZP7AkvhQV048qMYRbMGswrVOePeL5G8CMvyytTThVd4dqpouBA0BuhfvvzMY+ k2RIip619Aq1fpDlBjO45hpIceWwxo0SmX+OKYUPg9YM3a2JvxwWgzLsGRP8Cfn8 2hWSC/4TVbRXqbLgsUB8oe0pXJTy3PSxIWcZNGvv7vHSbe5VuPHXWQ+GGtxhPq6s dqWlC4vHVaFOwF1tTEFaOu4QcGbiI8cA+I8DMKatXLpvKaeBAkZZALdA90Ojy3ix WfDSyNNgXwpL9+MAd+lnuhwlwESdDfuF5iKhv4AKCmRGw6TNSqpWVcIfLX8+AGkn soE6P6mHEitCBmXoYKgcLvC2Ym7V4nYXd10iFWPvqCI9KFOMIsCgtueFHaxb9biN 3vR0I40CWNNCLofxVqkr9YF9HsWc1D7bspuOXCH/qK/deFNdYcWcptHREJ6hzfTC 6k6yGXfZY1I5PXbXRUHUJTceqYeNfiBF8d8jAK44auZymQHuOPveM5e+h2zfSpLv eTunLumGp1DqnJdamJOp =0bGI -----END PGP SIGNATURE----- --nextPart1725826.g29Ucdy8O6-- From nobody Tue Nov 29 05:05:35 2016 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 69354129559 for ; Tue, 29 Nov 2016 05:05:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 n-cnkmShNTfU for ; Tue, 29 Nov 2016 05:05:32 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 022D0129491 for ; Tue, 29 Nov 2016 05:05:24 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BB9237F7DF for ; Tue, 29 Nov 2016 13:05:23 +0000 (UTC) Received: from dhcp-10-40-1-102.brq.redhat.com ([10.40.3.199]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uATD5Lt0009169 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 29 Nov 2016 08:05:22 -0500 Message-ID: <1480424721.30876.4.camel@redhat.com> From: Nikos Mavrogiannopoulos To: Hubert Kario , tls@ietf.org Date: Tue, 29 Nov 2016 14:05:21 +0100 In-Reply-To: <38962934.NWKWaTxzK0@pintsize.usersys.redhat.com> References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> <38962934.NWKWaTxzK0@pintsize.usersys.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.28]); Tue, 29 Nov 2016 13:05:23 +0000 (UTC) Archived-At: Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Nov 2016 13:05:33 -0000 On Tue, 2016-11-29 at 13:56 +0100, Hubert Kario wrote: > > Given that certificates usually take up most of the bytes exchanged > > during a > > full handshake it seems this could be useful, but I don't know if > > in > > practice the benefits are worth the added complexity. Thoughts? > > Decompressing completely untrusted and unverified data directly in > the  > security library? > No, I don't think we need more complex code in TLS implementations. Well, PKIX/X.509 parsing seems to be order of magnitude more complex than compression :) regards, Nikos From nobody Tue Nov 29 05:20:59 2016 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 CD28B129A88 for ; Tue, 29 Nov 2016 05:20:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 atBtcQKoVGhv for ; Tue, 29 Nov 2016 05:20:55 -0800 (PST) Received: from brontes.bolet.org (brontes.bolet.org [62.210.214.227]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1BB3129AFA for ; Tue, 29 Nov 2016 05:20:54 -0800 (PST) Received: by brontes.bolet.org (Postfix, from userid 1000) id 3790D2076D; Tue, 29 Nov 2016 14:20:53 +0100 (CET) Date: Tue, 29 Nov 2016 14:20:53 +0100 From: Thomas Pornin To: tls@ietf.org Message-ID: <20161129132053.GA983@bolet.org> References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> <38962934.NWKWaTxzK0@pintsize.usersys.redhat.com> <1480424721.30876.4.camel@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1480424721.30876.4.camel@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Nov 2016 13:20:58 -0000 On Tue, Nov 29, 2016 at 02:05:21PM +0100, Nikos Mavrogiannopoulos wrote: > Well, PKIX/X.509 parsing seems to be order of magnitude more complex > than compression :) I have implemented both at times, so I can confirm that X.509 parsing is a bit more complex than decompression (with Deflate). The _compression_ is tougher. Another point which is worth pointing out is that decompression (again with Deflate, the algorithm inside gzip) works on repeating sequences in the past 32 kB window, so reliable implementation requires an up to 32 kB buffer. This won't make RAM-constrained people happy. --Thomas Pornin From nobody Tue Nov 29 05:28:15 2016 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 02A521298CE for ; Tue, 29 Nov 2016 05:28:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 0QorQlaJnwaM for ; Tue, 29 Nov 2016 05:28:12 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 71AF9129559 for ; Tue, 29 Nov 2016 05:28:12 -0800 (PST) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D8B09496C30; Tue, 29 Nov 2016 13:28:11 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id C2B03496C28; Tue, 29 Nov 2016 13:28:11 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480426091; bh=L8okkT2XIMNAX11UkYIJaGNc3Xtp2PtnRwveL1fOMvA=; l=506; h=From:To:Date:References:In-Reply-To:From; b=KIYz8He9V1iVFj5ba1NcfXaZCxsNB9BjWn2P+qGzoliFepVJm5TM0K5E06jpZ70iJ RsoCfDL6+gWxy4ahodVY6bzHfAHrYoIj/t9aPIOA6eECjfT6mSPY2AGShTGXbDwwyr vuNTn5gsTqyAsnhiE0bQ81wS3BnH9wmyflgL0j1w= Received: from email.msg.corp.akamai.com (usma1ex-cas3.msg.corp.akamai.com [172.27.123.32]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id A86371E080; Tue, 29 Nov 2016 13:28:11 +0000 (GMT) Received: from USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) by usma1ex-dag1mb6.msg.corp.akamai.com (172.27.123.65) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 29 Nov 2016 05:28:11 -0800 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by USMA1EX-EXJRNL1.msg.corp.akamai.com (172.27.123.99) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Tue, 29 Nov 2016 08:28:10 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Tue, 29 Nov 2016 08:28:11 -0500 From: "Salz, Rich" To: Nikos Mavrogiannopoulos , Hubert Kario , "tls@ietf.org" Thread-Topic: [TLS] Certificate compression (a la QUIC) for TLS 1.3 Thread-Index: AQHSSFE9tQg6unktJ0OB/Ghv4c6t66DwQ0CAgAACaYD//7H0UA== Date: Tue, 29 Nov 2016 13:28:10 +0000 Message-ID: <6d227dc55a2746cf80d57d4764d639b3@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20161127015437.kfcwpemeppg3yw7h@pinky.local> <38962934.NWKWaTxzK0@pintsize.usersys.redhat.com> <1480424721.30876.4.camel@redhat.com> In-Reply-To: <1480424721.30876.4.camel@redhat.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.32.142] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Nov 2016 13:28:14 -0000 U3VyZSwgaGVyZSdzIG15IGNvbXByZXNzZWQgY2VydC4gSWdub3JlIHRoZSBmYWN0IHRoYXQgaXQn cyBuYW1lZCAiNDIuemlwIiAtLSBzZWUgaHR0cHM6Ly9lbi53aWtpcGVkaWEub3JnL3dpa2kvWmlw X2JvbWINCg0KVGhlIHJpc2tzIG9mIHVuY29tcHJlc3NpbmcgZGF0YSBzZW50IGZyb20gYSBjb3Vu dGVycGFydHkgd2hvIGhhcyBub3QgeWV0IGJlZW4gYXV0aGVudGljYXRlZCwgZG8gbm90IG91dHdl aWdoIHRoZSBnYWlucy4NCg0KCS9yJA0KLS0gIA0KU2VuaW9yIEFyY2hpdGVjdCwgQWthbWFpIFRl Y2hub2xvZ2llcw0KTWVtYmVyLCBPcGVuU1NMIERldiBUZWFtDQpJTTogcmljaHNhbHpAamFiYmVy LmF0IFR3aXR0ZXI6IFJpY2hTYWx6DQoNCg== From nobody Tue Nov 29 05:47:45 2016 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 C7464129972 for ; Tue, 29 Nov 2016 05:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 qEqci29NQXOZ for ; Tue, 29 Nov 2016 05:47:41 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E15A21299A7 for ; Tue, 29 Nov 2016 05:47:38 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DBP44153; Tue, 29 Nov 2016 13:47:36 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml708-cah.china.huawei.com (10.201.5.202) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 29 Nov 2016 13:47:35 +0000 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.90]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0301.000; Tue, 29 Nov 2016 19:17:24 +0530 From: Raja ashok To: Sean Turner , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFfdArVH7ByyEedMDE3TizAfqDwCVTA Date: Tue, 29 Nov 2016 13:47:23 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1913B9DBLREML509MBXchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.583D86F8.0473, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.90, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 927648d9d32d225c82c06266509a3de3 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Nov 2016 13:47:44 -0000 --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1913B9DBLREML509MBXchi_ Content-Type: multipart/alternative; boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1913B9DBLREML509MBXchi_" --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1913B9DBLREML509MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SSBmZWVsIHdlIGNhbiBnbyBhaGVhZCB3aXRoIFRMUyAxLjMuDQoNCk9yIGVsc2UgVExTIDMuNCwg YmVjYXVzZSBhbnl3YXkgd2Ugc2VuZCAweDAzMDQgb24gd2lyZSBmb3IgVExTIDEuMy4NCg0KDQoN CkkgaG9wZSBhbGwgb3RoZXIgdGhyZWUgb3B0aW9ucyAoVExTIDIuMCwgVExTIDIgYW5kIFRMUyA0 KSB3aWxsIG1ha2UgY29uZnVzaW9uIHdpdGggU1NMIHZlcnNpb25zIGZvciBlbmQgdXNlci4NCg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpSYWphIEFzaG9rIFZLDQq7qs6q vLzK9dPQz965q8u+IEh1YXdlaSBUZWNobm9sb2dpZXMgQ28uLCBMdGQuDQpbQ29tcGFueV9sb2dv XQ0KDQpQaG9uZToNCkZheDoNCk1vYmlsZToNCkVtYWlsOg0KSHVhd2VpIFRlY2hub2xvZ2llcyBD by4sIEx0ZC4NCkJhbmdhbG9yZSwgSW5kaWENCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCrG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSx o8Pc0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737DQrWucjO us7G5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTW xqGiu/LJoreio6mxvtPKvP7W0A0KtcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0 tee7sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPKvP6joQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBh dHRhY2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwg d2hpY2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFk ZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFp bmVkIGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90 YWwgb3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9u KSBieSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJv aGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3Rp ZnkgdGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBp dCENCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIFttYWls dG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBTZWFuIFR1cm5lcg0KU2VudDog MTggTm92ZW1iZXIgMjAxNiAwNzo0Mw0KVG86IDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbVExT XSBDb25maXJtaW5nIGNvbnNlbnN1czogVExTMS4zLT5UTFMqDQoNCg0KDQpBdCBJRVRGIDk3LCB0 aGUgY2hhaXJzIGxlYWQgYSBkaXNjdXNzaW9uIHRvIHJlc29sdmUgd2hldGhlciB0aGUgV0cgc2hv dWxkIHJlYnJhbmQgVExTMS4zIHRvIHNvbWV0aGluZyBlbHNlLiAgU2xpZGVzIGNhbiBiZSBmb3Vu ZCBAIGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk3L3NsaWRlcy9zbGlkZXMtOTct dGxzLXJlYnJhbmRpbmctYWthLXByNjEyLTAxLnBkZi4NCg0KDQoNClRoZSBjb25zZW5zdXMgaW4g dGhlIHJvb20gd2FzIHRvIGxlYXZlIGl0IGFzIGlzLCBpLmUuLCBUTFMxLjMsIGFuZCB0byBub3Qg cmVicmFuZCBpdCB0byBUTFMgMi4wLCBUTFMgMiwgb3IgVExTIDQuICBXZSBuZWVkIHRvIGNvbmZp cm0gdGhpcyBkZWNpc2lvbiBvbiB0aGUgbGlzdCBzbyBwbGVhc2UgbGV0IHRoZSBsaXN0IGtub3cg eW91ciB0b3AgY2hvaWNlIGJldHdlZW46DQoNCg0KDQotIExlYXZlIGl0IFRMUyAxLjMNCg0KLSBS ZWJyYW5kIFRMUyAyLjANCg0KLSBSZWJyYW5kIFRMUyAyDQoNCi0gUmVicmFuZCBUTFMgNA0KDQoN Cg0KYnkgMiBEZWNlbWJlciAyMDE2Lg0KDQoNCg0KVGhhbmtzLA0KDQpKJlMNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KVExTIG1haWxpbmcgbGlz dA0KDQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCg== --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1913B9DBLREML509MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

I feel we can go ahead with TLS 1.3. <= /p>

Or else TLS 3.4, because anyway we send 0x0304 on= wire for TLS 1.3.

 

I hope all other three options (TLS 2.0, TLS 2 an= d TLS 4) will make confusion with SSL versions for end user.

 

Raja Ashok VK
=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologies Co., Ltd.
3D"Company_logo"

Phone:
Fax:
Mobile:
Email:
Huawei Technologies Co., Ltd.
Bangalore, India

http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE= =BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD= =F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6= =B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0= =CE=CA=BD=CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF= =BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7= =A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1= =CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA= =BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3= =A1
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

 

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sean Turner
Sent: 18 November 2016 07:43
To: <tls@ietf.org>
Subject: [TLS] Confirming consensus: TLS1.3->TLS*

 

At IETF 97, the chairs lead a discussion to resol= ve whether the WG should rebrand TLS1.3 to something else.  Slides can= be found @ https://www.ietf.org/= proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf.=

 

The consensus in the room was to leave it as is, = i.e., TLS1.3, and to not rebrand it to TLS 2.0, TLS 2, or TLS 4.  We n= eed to confirm this decision on the list so please let the list know your t= op choice between:

 

- Leave it TLS 1.3

- Rebrand TLS 2.0

- Rebrand TLS 2

- Rebrand TLS 4

 

by 2 December 2016.

 

Thanks,

J&S

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf= .org/mailman/listinfo/tls

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1913B9DBLREML509MBXchi_-- --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1913B9DBLREML509MBXchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Tue, 29 Nov 2016 13:47:23 GMT"; modification-date="Tue, 29 Nov 2016 13:47:23 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1913B9DBLREML509MBXchi_-- From nobody Tue Nov 29 10:55:27 2016 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 E5D60129C41 for ; Tue, 29 Nov 2016 10:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 unDVxcRsel7W for ; Tue, 29 Nov 2016 10:55:24 -0800 (PST) Received: from brontes.bolet.org (brontes.bolet.org [62.210.214.227]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD3D8129C3D for ; Tue, 29 Nov 2016 10:55:23 -0800 (PST) Received: by brontes.bolet.org (Postfix, from userid 1000) id D89A02076D; Tue, 29 Nov 2016 19:54:51 +0100 (CET) Date: Tue, 29 Nov 2016 19:54:51 +0100 From: Thomas Pornin To: "Fossati, Thomas (Nokia - GB)" Message-ID: <20161129185451.GA4541@bolet.org> References: <20161124195002.GA32346@bolet.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Maximum Fragment Length negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Tue, 29 Nov 2016 18:55:26 -0000 On Thu, Nov 24, 2016 at 09:10:00PM +0000, Fossati, Thomas (Nokia - GB) wrote: > I like your proposal, but I'm not convinced that overloading the > semantics of an already existing extension when used in combination > with a specific version of the protocol is necessarily the best > strategy. Besides, I'd like to be able to deploy a similar mechanism > in 1.2. Defining a new extension is certainly possible. However, it would then require deciding on the intended behaviour when both that new extension and the RFC 6066 extension are present. Tentatively, one could try this: - The new extension documents the maximum record length supported by whoever sends it. Encoding is as in RFC 6066: one byte of value x for a maximum record plaintext length of 2^(x+8) bytes). We extend that to the whole 1..8 range so that larger records may be used by implementations who can afford them and obtain some performance increase by doing so (actual maximum plaintext length will be slightly less than 65535 bytes becose the length header is 16-bit and there must be some room for the MAC). - If a client sends both the RFC 6066 extension and the new extension, and the server supports the new extension, then the RFC 6066 extension is ignored and only the new extension is used. A server MUST NOT send both extensions. - All implementations that support the extension MUST have the ability to apply a shorter size limit than their maximum limit (this is for _sending_ records). - The length sent by the server is the one that will be applied to subsequent records on the connection, in both directions. This applies to the whole connection, including subsequent handshakes (renegotiations), unless both client and server send the new extension again in a renegotiation (in which case the new length appplies). - If using TLS 1.3, then the following extra rules apply: - All TLS 1.3 implementations MUST support the extension. - If the client does not send the new extension, then this is equivalent to the client sending the new extension with a value of 6 (i.e. maximum plaintext length is 2^14 = 16384 bytes). In particular, this allows the server to send the extension. - If the server does not send the new extension, then this is equivalent to the server sending the new extension with the same value as the one from the client. (So, if neither sends the extension, then the usual 16384-byte limit applies.) - If using TLS 1.2 or a previous version, then there is no implicit usage: - The server MUST NOT send the new extension unless the client sent it. - The maximum plaintext limit shall be enforced only if the server sent the extension; that limit is the one defined by the server's extension. - If the client and/or the server does not send the extension, then the maximum plaintext length is the one that was in force at that point, i.e. 16384 bytes for a new connection, or whatever was used before the new handshake in case of renegotiation. Some noteworthy points: * TLS 1.3 has no renegotiation, so the renegotiation behaviour is for TLS 1.2 and previous. This avoids tricky issues with the TLS 1.3 implicit behaviour in case of renegotiation. * A client SHOULD send the new extension in all ClientHello if it is ready to use TLS 1.2 or previous, so that a non-1.3-aware server may have the possibility to negotiate a shorter maximum plaintext length. * The initial ClientHello may use records larger than what the server is willing to accept, and before the server has any chance to advertise its own maximum record size. However, since the initial records are unprotected, implementations may be able to process partial records, and thus could accept un-MACed records larger than their incoming buffer (at least BearSSL can do that). The "implicit" behaviour (both for client and server) with TLS 1.3 is a way to make the extension free (with regards to network usage) in the common case. It cannot be applied unless the extension support is made mandatory for TLS 1.3. Making it mandatory is also an important feature, since otherwise such an extension would likely remain unimplemented by "big" clients (e.g. Web browsers). Any comments? I can try to write the corresponding text for inclusion in the TLS 1.3 draft. What is the process for submitting such text? --Thomas Pornin From nobody Tue Nov 29 16:20:07 2016 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 727F4129CF5 for ; Tue, 29 Nov 2016 16:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XlkpH1yUCmX for ; Tue, 29 Nov 2016 16:20:02 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (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 58D22129CE7 for ; Tue, 29 Nov 2016 16:20:02 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id x190so193438814qkb.0 for ; Tue, 29 Nov 2016 16:20:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lasQaI9FH1cjtKzkiJjpC5aYDWlhYgRQkTaCrf93MVg=; b=jTUCx28Y2DFdZPBI7lbb1dh+s6qBH3/JVHB3ofT3//8mJb+Lf//BkHQOFnMtDYXnMr mVcKYJBKd7KJyO5f6d9O1YaE45s8i67miEkZyayFSRr4ACCn0bDg2t3klc+QX7wnRDNJ +6yQXTF83EGfC7RI2EzSq6G52/NgmQVDoj28cBUAxYwmTf8fM56lRElH8zvhpz1Fuq+S 3gdjJ9vsKLGVbPG6krP8/brDD04BgGSzqev64Lq5xsfTK53UbE+0hXtDnLkNlKwDZ5s/ sn67r5aVELnyvaL5qbKVmGzmoKyKdBPsbfjeF7MCLj4RyVwjdIeYajWAzSI7CRm/lTJ5 WC2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lasQaI9FH1cjtKzkiJjpC5aYDWlhYgRQkTaCrf93MVg=; b=hG2TH7kbMlFmkEJB+iT7cyypT+TEpb3sz4lUPbYo5Sk6BLsnN6NAx6egbd1ovBb2QR cuNXLf8EV/DOYt7h0ClkjiB7LnQ0wgcVtn7sY/z6aYBry6SEqJii2XgIrTEGxwDO2iUe 8Z2Iwzard6xzRxyjOX1nuWtMRlHs7P/o7HDqWoxlrNIlvicqV6BkBPmXFRJz5HCxHnAr sRfD5qJX12SB51s8yqTWrWnmAovmpDrVIW7RXoKam3kKPrkFZ+RkKhS7ZpSws5kl/1VE sAJGSQhSP6K5LzVtOL3dODzspwejf7odQN/tmXlykn2sgMPviFg9dITuC5NzmjPFUVxN J7ew== X-Gm-Message-State: AKaTC03zMAckdqgJxjOsj4rNtuWBgXMbx3hTC/CS359L9p7dNfXsBxNs0T/zhtN5ytk2aJStLPDtqfjFff9dTg== X-Received: by 10.55.12.2 with SMTP id 2mr26656204qkm.68.1480465201502; Tue, 29 Nov 2016 16:20:01 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Tue, 29 Nov 2016 16:20:01 -0800 (PST) In-Reply-To: <20161129185451.GA4541@bolet.org> References: <20161124195002.GA32346@bolet.org> <20161129185451.GA4541@bolet.org> From: Martin Thomson Date: Wed, 30 Nov 2016 11:20:01 +1100 Message-ID: To: Thomas Pornin Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Maximum Fragment Length negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Nov 2016 00:20:04 -0000 On 30 November 2016 at 05:54, Thomas Pornin wrote: > Any comments? I'm ambivalent on this generally: though I think that the general notion is OK, I'm not sure about the details. In particular, you need to be clearer in your motivations: the point is to ensure that little things (really little things) can talk to any other TLS implementation. That seems inherently good, but it might pay to dig into that some more: why is that good? I would be opposed to having an implicit extension in the way you describe. If you are going to require this, then you need to require the client to send the extension. I would also be opposed to a new extension when the existing one is adequate - or it could be made to be adequate. I agree that the current extension semantics are not good. Ideally we would want 2^13 and 2^14, and an agreement to use min(client_mfl, server_mfl) rather than having the server dictate. That might mean a new extension, but I'm not sure. > I can try to write the corresponding text for inclusion in the TLS 1.3 > draft. What is the process for submitting such text? The spec is on github: https://github.com/tlswg/tls13-spec You can create a pull request. However, I am going to suggest that this is a pretty big change. It's already late. It might be better to create a new draft that revises the maximum fragment length extension (or defines a better replacement). (As an aside, the success rate for RFC 6066 is pretty low in retrospect, maybe there's an object lesson there.) From nobody Tue Nov 29 19:04:49 2016 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 D65E2128DF6 for ; Tue, 29 Nov 2016 19:04:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 CEV80qhc5Df6 for ; Tue, 29 Nov 2016 19:04:35 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (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 1B4EA129D25 for ; Tue, 29 Nov 2016 19:04:20 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id t125so149694880ywc.1 for ; Tue, 29 Nov 2016 19:04:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=rdaUqLd5ItiCMs1ftd3y9nZK1MZkye4GTqKtMMWplQs=; b=W7hZRf/QyDBwkcAdaPpsWzOFD66Fc0IexyeTJXBN1xUdutTtimNexAtcn7YfAnd1fB RNr09K+8YsmSpSyLFLlduDAwQZSuCqJjfV2E3wbO8cqaRX3353bRNBBVwnxH7msEff3y R4LPytnfnqSTzB2LHlrlcmHOb/fRz8+qIWkclNDNkw2fR3tBWVNZMiB2UIuTQ3tF0uGk ZuFFURHO+4CGDA0Wf14jJgHriJNN18deHo0agMBCL75jUh7D4Gv+u6RfGqJ3VH7IBf7h 1DQPp1YFba6qr3t+5X1WagViv0SGJ3Rgjiv/uREH/ElN2Pb1N5ba+cM9IRSPbPlb6vLe pYwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rdaUqLd5ItiCMs1ftd3y9nZK1MZkye4GTqKtMMWplQs=; b=fzQfVT67IORwtAF4qaefRGABRr/uNZQtQWiEuC+kAZ9RXlgrnZ4mTs4JYb69rmEXcG FqWWROiTFLVt5xgwEfBUehKPevV6+yAwvyubYPmQzdjPqG9zvyWv0kUCx+9acoSvbC5A LT0Evwd3NmowC3pvzmZeu3lbeiK2KoaE7tB7B/ISne9AD3PW/1CSYjdCs9EL7CUE9Ov6 Pma4Tyo4HEPzP5GyQu+j/C9CsvbVufIrLRNuUMStUweTvSyM6CeXjdsA972AAi880v/7 nfnXpxZrObA/JbSHro878i3j1PUbgbPIUC4Ta6FLg8lu0I4rXAMD4IPLKsa5Wd2OPlet bYWQ== X-Gm-Message-State: AKaTC00znJM6jK8srbTCawsEGF7FRdmYoNtsm29uxodpN232bOLmejafrSkt9i4ndgTlRq9XAyNRavmBwP17Qg== X-Received: by 10.13.195.5 with SMTP id f5mr38168793ywd.354.1480475059053; Tue, 29 Nov 2016 19:04:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Tue, 29 Nov 2016 19:03:38 -0800 (PST) From: Eric Rescorla Date: Tue, 29 Nov 2016 22:03:38 -0500 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114d5fd6fea0c205427bf50e Archived-At: Subject: [TLS] PR# CertificateRequest extensions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Nov 2016 03:04:38 -0000 --001a114d5fd6fea0c205427bf50e Content-Type: text/plain; charset=UTF-8 As discussed in issue #760 and Seoul, I've prepared a PR that moves most all of CertificateRequest into extensions: https://github.com/tlswg/tls13-spec/pull/791 This got a little more complicated than I anticipated because I had to actually define a certificate_authorities extension and I decided to give it some semantics when the client sent it (displacing trusted_ca_keys, which seems unused and kinda busted). Target merge date: Friday. -Ekr --001a114d5fd6fea0c205427bf50e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
As discussed in issue #760 and Seoul, I've prepared a = PR that moves most all
of CertificateRequest into extensions:


This got a little more complicated than I anticipated because I had to act= ually
define a certificate_authorities extension and I decided to= give it some semantics
when the client sent it (displacing trust= ed_ca_keys, which seems unused and
kinda busted).

<= /div>
Target merge date: Friday.

-Ekr

--001a114d5fd6fea0c205427bf50e-- From nobody Wed Nov 30 01:34:57 2016 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 BE930129E3F for ; Wed, 30 Nov 2016 01:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.878 X-Spam-Level: X-Spam-Status: No, score=-0.878 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, SPF_FAIL=0.001] autolearn=no autolearn_force=no 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 8dZkKnxCe8CD for ; Wed, 30 Nov 2016 01:34:54 -0800 (PST) Received: from garfield.picty.org (garfield.picty.org [82.231.235.137]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 883C0129E44 for ; Wed, 30 Nov 2016 01:31:25 -0800 (PST) Received: from neoplankton.picty.org (unknown [80.12.37.42]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by garfield.picty.org (Postfix) with ESMTPSA id 151C953FA1; Wed, 30 Nov 2016 09:31:21 +0000 (UTC) Date: Wed, 30 Nov 2016 10:34:00 +0100 From: Olivier Levillain Message-ID: <20161130093357.GA24902@neoplankton.picty.org> References: <20161122190822.GH19978@neoplankton.picty.org> <58355C92.8070504@ssi.gouv.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <58355C92.8070504@ssi.gouv.fr> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Draft 18 review : Message splitting and interleaving X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Nov 2016 09:34:55 -0000 Hi list, I just proposed a new PR (#798) concerning the text in 5.1 (Record layer), following the discussion here (and not including the extra Handshake constraints). Best regards, olivier From nobody Wed Nov 30 02:49:24 2016 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 A5A80129651 for ; Wed, 30 Nov 2016 02:49:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no 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 mjuESpm98NQY for ; Wed, 30 Nov 2016 02:49:18 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD8F4129F22 for ; Wed, 30 Nov 2016 02:49:11 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CWH40092; Wed, 30 Nov 2016 10:49:07 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 30 Nov 2016 10:49:00 +0000 Received: from BLREML509-MBX.china.huawei.com ([169.254.7.90]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0301.000; Wed, 30 Nov 2016 16:18:49 +0530 From: Raja ashok To: Thomas Pornin , "Fossati, Thomas (Nokia - GB)" Thread-Topic: [TLS] Maximum Fragment Length negotiation Thread-Index: AQHSSnJUUXQAYc6WmEWL9A2VSlDz2KDxTA1w Date: Wed, 30 Nov 2016 10:48:49 +0000 Message-ID: References: <20161124195002.GA32346@bolet.org> <20161129185451.GA4541@bolet.org> In-Reply-To: <20161129185451.GA4541@bolet.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: multipart/related; boundary="_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1913EACBLREML509MBXchi_"; type="multipart/alternative" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.583EAEA5.045D, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.7.90, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 8d984ef14dd4107c0d3325b626759228 Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Maximum Fragment Length negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Nov 2016 10:49:20 -0000 --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1913EACBLREML509MBXchi_ Content-Type: multipart/alternative; boundary="_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1913EACBLREML509MBXchi_" --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1913EACBLREML509MBXchi_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 SGkgVGhvbWFzDQoNCg0KDQpZb3VyIGlkZWEgb2YgZGVmaW5pbmcgYSBuZXcgc2ltaWxhciBleHRl bnNpb24gaXMgdGhlIG9ubHkgY2hvaWNlIGZvciB1cy4gQmVjYXVzZSBhcyBwZXIgZXhpc3Rpbmcg bWF4X2ZyYWdtZW50X2xlbmd0aCBleHRlbnNpb24gaW4gUkZDIDYwNjYsIGNsaWVudCBzaG91bGQg ZmFpbCBpZiBpdCByZWNlaXZlcyBkaWZmZXJlbnQgdmFsdWUgZnJvbSBzZXJ2ZXIuDQoNCkFuZCBh bHNvIHlvdXIgaWRlYSBvZiBtYWtpbmcgdGhlIG5ldyBleHRlbnNpb24gYXMgbWFuZGF0b3J5IGZv ciBUTFMxLjMgaXMgZ29vZCwgYXMgaXQgd2lsbCBiZSBtb3JlIHVzZWZ1bCBmb3IgY29uc3RyYWlu dCBzZXJ2ZXIuDQoNCg0KDQpFYXJsaWVyIGluIG91ciB0ZWFtIGFsc28gd2Ugd2VyZSBkaXNjdXNz aW5nIGFib3V0IGRlZmluaW5nIG5ldyBleHRlbnNpb24gc3BlY2lhbGx5IGZvciBjb25zdHJhaW50 IGNsaWVudCBhbmQgc2VydmVyLiBJIHN1Z2dlc3Qgd2Ugc2hvdWxkIGluY2x1ZGUgdGhlIGJlbG93 IHBvaW50cyBmb3IgbmV3IGZyYWdtZW50IGxlbmd0aCBleHRlbnNpb24NCg0KICAgICAgMSkgQXMg cGVyIFJGQyA2MDY2LCBpZiA1MTIgaXMgbmVnb3RpYXRlZCB0aGVuIGJvdGggZW50aXR5IHNob3Vs ZCBrZWVwIGJ1ZmZlciBvZiBzaXplIDgwNSBieXRlcyAoNSBieXRlIC0gcmVjb3JkIGhlYWRlciwg NTEyIGJ5dGVzIC0gZGF0YSwgMjU2IGJ5dGVzIC0gcGFkZGluZywgMzIgYnl0ZXMgLSBNQUMpLiBJ IHRoaW5rIHdlIHNob3VsZCBjaGFuZ2UgdGhpcyBpbiBvdXIgbmV3IGZyYWdtZW50IGV4dGVuc2lv bi4gSWYgNTEyIGlzIG5lZ290aWF0ZWQgdGhlbiBib3RoIGVudGl0eSBzaG91bGQgbm90IHNlbmQg YW55IFtEXVRMUyByZWNvcmQgb2Ygc2l6ZSBtb3JlIHRoYW4gdGhhdCAoaW5jbHVkZXMgcmVjb3Jk IGhlYWRlciBhbmQgcGF5bG9hZCkuICBCZWNhdXNlIHRoZSBjb250cm9sIG92ZXJoZWFkIG9mIDI1 NiBieXRlcyBwYWRkaW5nIGFuZCAzMiBieXRlcyBNQUMgYXJlIG5vdCBhcHBsaWNhYmxlIGZvciBy ZWNlbnQgQUVBRCBhbGdvcml0aG1zLiBUaGF0IHRvbyBpbiBBRVNfQ0NNIHRoZXJlIGlzIG5vIG5l ZWQgb2YgcGFkZGluZy4NCg0KICAgICAgMikgQ3VycmVudGx5IGxlYXN0IHZhbHVlIHN1cHBvcnRl ZCBieSBtYXhfZnJhZ21lbnRfbGVuZ3RoIGlzIDUxMi4gSSBwcmVmZXIgd2Ugc2hvdWxkIGFkZCBz dXBwb3J0IGZvciAyNTYgYW5kIDEyOCBhbHNvLiBJZiBBRVNfQ0NNXzggaXMgdXNlZCwgdGhlIGNv bnRyb2wgb3ZlcmhlYWQgb24gYXBwbGljYXRpb24gcmVjb3JkIGlzIDIxIGJ5dGVzICg1IGJ5dGUg LSByZWNvcmQgaGVhZGVyLCA4IGJ5dGUgLSBJViBhbmQgOCBieXRlIC0gTUlDKS4gSWYgaXRzIERU TFMgcmVjb3JkLCBvdmVyaGVhZCBpcyAyOSBieXRlcy4gU28gaWYgbWF4IGZyYWdtZW50IGxlbmd0 aCBpcyAxMjgsIHdlIGdldCA5OSBieXRlcyBmb3IgZGF0YS4gVGhpcyBpcyBtb3JlIHRoYW4gc3Vm ZmljaWVudCBmb3IgYSBjb25zdHJhaW50IHByb3RvY29sIGxpa2UgQ29BUC4NCg0KICAgICAgTm90 ZSA6IEV4aXN0aW5nIG1heF9mcmFnbWVudF9sZW5ndGggZXh0ZW5zaW9uIGNhbm5vdCBiZSBleHRl bmRlZCB0byBzdXBwb3J0IG5ldyB2YWx1ZXMgbGlrZSAxMjggYW5kIDI1Ni4NCg0KICAgICAgMykg SWYgYSBjbGllbnQgc2VuZHMgYm90aCBvbGQgYW5kIG5ldyBleHRlbnNpb24sIHRoZW4gcHJpb3Jp dHkgc2hvdWxkIGJlIGdpdmVuIHRvIG5ldyBleHRlbnNpb24uIFNlcnZlciBNVVNUIG5vdCBzZW5k IGJvdGggdGhlIGV4dGVuc2lvbi4NCg0KDQoNCkkgZmVlbCB0aGUgY3VycmVudCBJb1Qgd29ybGQg bmVlZHMgdGhpcyBraW5kIG9mIG5ldyBleHRlbnNpb24uIFRoaXMgaXMgdGhlIHRpbWUgdG8gZG8u DQoNCg0KDQpSZWdhcmRzLA0KDQpBc2hvaw0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NClJhamEgQXNob2sgVksNCruqzqq8vMr109DP3rmry74gSHVhd2VpIFRlY2hub2xv Z2llcyBDby4sIEx0ZC4NCltDb21wYW55X2xvZ29dDQoNClBob25lOg0KRmF4Og0KTW9iaWxlOg0K RW1haWw6DQq12Na3o7rJ7tvaytDB+rjax/jb4Mzvu6rOqrv5tdgg08qx4KO6NTE4MTI5DQpIdWF3 ZWkgVGVjaG5vbG9naWVzIENvLiwgTHRkLg0KQmFudGlhbiwgTG9uZ2dhbmcgRGlzdHJpY3QsU2hl bnpoZW4gNTE4MTI5LCBQLlIuQ2hpbmENCmh0dHA6Ly93d3cuaHVhd2VpLmNvbQ0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCrG+08q8/rywxuS4vbz+uqzT0Luqzqq5q8u+tcSxo8Pc 0MXPoqOsvfbP3tPat6LLzbj4yc/D5rXY1rfW0MHQs/a1xLj2yMu78si61+mho737DQrWucjOus7G 5Mv7yMvS1MjOus7Qzsq9yrnTw6OosPzAqLWrsrvP3tPayKuyv7vysr+31rXY0LnCtqGiuLTWxqGi u/LJoreio6mxvtPKvP7W0A0KtcTQxc+ioaPI57n7xPq07crVwcuxvtPKvP6jrMfrxPrBory0tee7 sLvy08q8/s2o1qq3orz+yMuyosm+s/2xvtPKvP6joQ0KVGhpcyBlLW1haWwgYW5kIGl0cyBhdHRh Y2htZW50cyBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiBmcm9tIEhVQVdFSSwgd2hp Y2gNCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBwZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJl c3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9mIHRoZQ0KaW5mb3JtYXRpb24gY29udGFpbmVk IGhlcmVpbiBpbiBhbnkgd2F5IChpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgdG90YWwg b3IgcGFydGlhbA0KZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBvciBkaXNzZW1pbmF0aW9uKSBi eSBwZXJzb25zIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQpyZWNpcGllbnQocykgaXMgcHJvaGli aXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBlLW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBieQ0KcGhvbmUgb3IgZW1haWwgaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSBpdCEN Cg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogVExTIFttYWlsdG86 dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBUaG9tYXMgUG9ybmluDQpTZW50OiAz MCBOb3ZlbWJlciAyMDE2IDAwOjI1DQpUbzogRm9zc2F0aSwgVGhvbWFzIChOb2tpYSAtIEdCKQ0K Q2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIE1heGltdW0gRnJhZ21lbnQgTGVu Z3RoIG5lZ290aWF0aW9uDQoNCg0KDQpPbiBUaHUsIE5vdiAyNCwgMjAxNiBhdCAwOToxMDowMFBN ICswMDAwLCBGb3NzYXRpLCBUaG9tYXMgKE5va2lhIC0gR0IpDQoNCndyb3RlOg0KDQo+IEkgbGlr ZSB5b3VyIHByb3Bvc2FsLCBidXQgSSdtIG5vdCBjb252aW5jZWQgdGhhdCBvdmVybG9hZGluZyB0 aGUNCg0KPiBzZW1hbnRpY3Mgb2YgYW4gYWxyZWFkeSBleGlzdGluZyBleHRlbnNpb24gd2hlbiB1 c2VkIGluIGNvbWJpbmF0aW9uDQoNCj4gd2l0aCBhIHNwZWNpZmljIHZlcnNpb24gb2YgdGhlIHBy b3RvY29sIGlzIG5lY2Vzc2FyaWx5IHRoZSBiZXN0DQoNCj4gc3RyYXRlZ3kuICBCZXNpZGVzLCBJ J2QgbGlrZSB0byBiZSBhYmxlIHRvIGRlcGxveSBhIHNpbWlsYXIgbWVjaGFuaXNtDQoNCj4gaW4g MS4yLg0KDQoNCg0KRGVmaW5pbmcgYSBuZXcgZXh0ZW5zaW9uIGlzIGNlcnRhaW5seSBwb3NzaWJs ZS4gSG93ZXZlciwgaXQgd291bGQgdGhlbiByZXF1aXJlIGRlY2lkaW5nIG9uIHRoZSBpbnRlbmRl ZCBiZWhhdmlvdXIgd2hlbiBib3RoIHRoYXQgbmV3IGV4dGVuc2lvbiBhbmQgdGhlIFJGQyA2MDY2 IGV4dGVuc2lvbiBhcmUgcHJlc2VudC4NCg0KDQoNClRlbnRhdGl2ZWx5LCBvbmUgY291bGQgdHJ5 IHRoaXM6DQoNCg0KDQogIC0gVGhlIG5ldyBleHRlbnNpb24gZG9jdW1lbnRzIHRoZSBtYXhpbXVt IHJlY29yZCBsZW5ndGggc3VwcG9ydGVkDQoNCiAgICBieSB3aG9ldmVyIHNlbmRzIGl0LiBFbmNv ZGluZyBpcyBhcyBpbiBSRkMgNjA2Njogb25lIGJ5dGUgb2YNCg0KICAgIHZhbHVlIHggZm9yIGEg bWF4aW11bSByZWNvcmQgcGxhaW50ZXh0IGxlbmd0aCBvZiAyXih4KzgpIGJ5dGVzKS4NCg0KICAg IFdlIGV4dGVuZCB0aGF0IHRvIHRoZSB3aG9sZSAxLi44IHJhbmdlIHNvIHRoYXQgbGFyZ2VyIHJl Y29yZHMNCg0KICAgIG1heSBiZSB1c2VkIGJ5IGltcGxlbWVudGF0aW9ucyB3aG8gY2FuIGFmZm9y ZCB0aGVtIGFuZCBvYnRhaW4NCg0KICAgIHNvbWUgcGVyZm9ybWFuY2UgaW5jcmVhc2UgYnkgZG9p bmcgc28gKGFjdHVhbCBtYXhpbXVtIHBsYWludGV4dA0KDQogICAgbGVuZ3RoIHdpbGwgYmUgc2xp Z2h0bHkgbGVzcyB0aGFuIDY1NTM1IGJ5dGVzIGJlY29zZSB0aGUgbGVuZ3RoDQoNCiAgICBoZWFk ZXIgaXMgMTYtYml0IGFuZCB0aGVyZSBtdXN0IGJlIHNvbWUgcm9vbSBmb3IgdGhlIE1BQykuDQoN Cg0KDQogIC0gSWYgYSBjbGllbnQgc2VuZHMgYm90aCB0aGUgUkZDIDYwNjYgZXh0ZW5zaW9uIGFu ZCB0aGUgbmV3IGV4dGVuc2lvbiwNCg0KICAgIGFuZCB0aGUgc2VydmVyIHN1cHBvcnRzIHRoZSBu ZXcgZXh0ZW5zaW9uLCB0aGVuIHRoZSBSRkMgNjA2Ng0KDQogICAgZXh0ZW5zaW9uIGlzIGlnbm9y ZWQgYW5kIG9ubHkgdGhlIG5ldyBleHRlbnNpb24gaXMgdXNlZC4gQSBzZXJ2ZXINCg0KICAgIE1V U1QgTk9UIHNlbmQgYm90aCBleHRlbnNpb25zLg0KDQoNCg0KICAtIEFsbCBpbXBsZW1lbnRhdGlv bnMgdGhhdCBzdXBwb3J0IHRoZSBleHRlbnNpb24gTVVTVCBoYXZlIHRoZQ0KDQogICAgYWJpbGl0 eSB0byBhcHBseSBhIHNob3J0ZXIgc2l6ZSBsaW1pdCB0aGFuIHRoZWlyIG1heGltdW0gbGltaXQN Cg0KICAgICh0aGlzIGlzIGZvciBfc2VuZGluZ18gcmVjb3JkcykuDQoNCg0KDQogIC0gVGhlIGxl bmd0aCBzZW50IGJ5IHRoZSBzZXJ2ZXIgaXMgdGhlIG9uZSB0aGF0IHdpbGwgYmUgYXBwbGllZCB0 bw0KDQogICAgc3Vic2VxdWVudCByZWNvcmRzIG9uIHRoZSBjb25uZWN0aW9uLCBpbiBib3RoIGRp cmVjdGlvbnMuIFRoaXMNCg0KICAgIGFwcGxpZXMgdG8gdGhlIHdob2xlIGNvbm5lY3Rpb24sIGlu Y2x1ZGluZyBzdWJzZXF1ZW50IGhhbmRzaGFrZXMNCg0KICAgIChyZW5lZ290aWF0aW9ucyksIHVu bGVzcyBib3RoIGNsaWVudCBhbmQgc2VydmVyIHNlbmQgdGhlIG5ldw0KDQogICAgZXh0ZW5zaW9u IGFnYWluIGluIGEgcmVuZWdvdGlhdGlvbiAoaW4gd2hpY2ggY2FzZSB0aGUgbmV3IGxlbmd0aA0K DQogICAgYXBwcGxpZXMpLg0KDQoNCg0KICAtIElmIHVzaW5nIFRMUyAxLjMsIHRoZW4gdGhlIGZv bGxvd2luZyBleHRyYSBydWxlcyBhcHBseToNCg0KDQoNCiAgICAgLSBBbGwgVExTIDEuMyBpbXBs ZW1lbnRhdGlvbnMgTVVTVCBzdXBwb3J0IHRoZSBleHRlbnNpb24uDQoNCg0KDQogICAgIC0gSWYg dGhlIGNsaWVudCBkb2VzIG5vdCBzZW5kIHRoZSBuZXcgZXh0ZW5zaW9uLCB0aGVuIHRoaXMgaXMN Cg0KICAgICAgIGVxdWl2YWxlbnQgdG8gdGhlIGNsaWVudCBzZW5kaW5nIHRoZSBuZXcgZXh0ZW5z aW9uIHdpdGggYQ0KDQogICAgICAgdmFsdWUgb2YgNiAoaS5lLiBtYXhpbXVtIHBsYWludGV4dCBs ZW5ndGggaXMgMl4xNCA9IDE2Mzg0IGJ5dGVzKS4NCg0KICAgICAgIEluIHBhcnRpY3VsYXIsIHRo aXMgYWxsb3dzIHRoZSBzZXJ2ZXIgdG8gc2VuZCB0aGUgZXh0ZW5zaW9uLg0KDQoNCg0KICAgICAt IElmIHRoZSBzZXJ2ZXIgZG9lcyBub3Qgc2VuZCB0aGUgbmV3IGV4dGVuc2lvbiwgdGhlbiB0aGlz IGlzDQoNCiAgICAgICBlcXVpdmFsZW50IHRvIHRoZSBzZXJ2ZXIgc2VuZGluZyB0aGUgbmV3IGV4 dGVuc2lvbiB3aXRoIHRoZQ0KDQogICAgICAgc2FtZSB2YWx1ZSBhcyB0aGUgb25lIGZyb20gdGhl IGNsaWVudC4gKFNvLCBpZiBuZWl0aGVyIHNlbmRzDQoNCiAgICAgICB0aGUgZXh0ZW5zaW9uLCB0 aGVuIHRoZSB1c3VhbCAxNjM4NC1ieXRlIGxpbWl0IGFwcGxpZXMuKQ0KDQoNCg0KICAtIElmIHVz aW5nIFRMUyAxLjIgb3IgYSBwcmV2aW91cyB2ZXJzaW9uLCB0aGVuIHRoZXJlIGlzIG5vIGltcGxp Y2l0DQoNCiAgICB1c2FnZToNCg0KDQoNCiAgICAgLSBUaGUgc2VydmVyIE1VU1QgTk9UIHNlbmQg dGhlIG5ldyBleHRlbnNpb24gdW5sZXNzIHRoZSBjbGllbnQgc2VudA0KDQogICAgICAgaXQuDQoN Cg0KDQogICAgIC0gVGhlIG1heGltdW0gcGxhaW50ZXh0IGxpbWl0IHNoYWxsIGJlIGVuZm9yY2Vk IG9ubHkgaWYgdGhlIHNlcnZlcg0KDQogICAgICAgc2VudCB0aGUgZXh0ZW5zaW9uOyB0aGF0IGxp bWl0IGlzIHRoZSBvbmUgZGVmaW5lZCBieSB0aGUgc2VydmVyJ3MNCg0KICAgICAgIGV4dGVuc2lv bi4NCg0KDQoNCiAgICAgLSBJZiB0aGUgY2xpZW50IGFuZC9vciB0aGUgc2VydmVyIGRvZXMgbm90 IHNlbmQgdGhlIGV4dGVuc2lvbiwgdGhlbg0KDQogICAgICAgdGhlIG1heGltdW0gcGxhaW50ZXh0 IGxlbmd0aCBpcyB0aGUgb25lIHRoYXQgd2FzIGluIGZvcmNlIGF0IHRoYXQNCg0KICAgICAgIHBv aW50LCBpLmUuIDE2Mzg0IGJ5dGVzIGZvciBhIG5ldyBjb25uZWN0aW9uLCBvciB3aGF0ZXZlciB3 YXMNCg0KICAgICAgIHVzZWQgYmVmb3JlIHRoZSBuZXcgaGFuZHNoYWtlIGluIGNhc2Ugb2YgcmVu ZWdvdGlhdGlvbi4NCg0KDQoNClNvbWUgbm90ZXdvcnRoeSBwb2ludHM6DQoNCg0KDQogICogVExT IDEuMyBoYXMgbm8gcmVuZWdvdGlhdGlvbiwgc28gdGhlIHJlbmVnb3RpYXRpb24gYmVoYXZpb3Vy IGlzDQoNCiAgICBmb3IgVExTIDEuMiBhbmQgcHJldmlvdXMuIFRoaXMgYXZvaWRzIHRyaWNreSBp c3N1ZXMgd2l0aCB0aGUNCg0KICAgIFRMUyAxLjMgaW1wbGljaXQgYmVoYXZpb3VyIGluIGNhc2Ug b2YgcmVuZWdvdGlhdGlvbi4NCg0KDQoNCiAgKiBBIGNsaWVudCBTSE9VTEQgc2VuZCB0aGUgbmV3 IGV4dGVuc2lvbiBpbiBhbGwgQ2xpZW50SGVsbG8gaWYgaXQNCg0KICAgIGlzIHJlYWR5IHRvIHVz ZSBUTFMgMS4yIG9yIHByZXZpb3VzLCBzbyB0aGF0IGEgbm9uLTEuMy1hd2FyZQ0KDQogICAgc2Vy dmVyIG1heSBoYXZlIHRoZSBwb3NzaWJpbGl0eSB0byBuZWdvdGlhdGUgYSBzaG9ydGVyIG1heGlt dW0NCg0KICAgIHBsYWludGV4dCBsZW5ndGguDQoNCg0KDQogICogVGhlIGluaXRpYWwgQ2xpZW50 SGVsbG8gbWF5IHVzZSByZWNvcmRzIGxhcmdlciB0aGFuIHdoYXQgdGhlIHNlcnZlcg0KDQogICBp cyB3aWxsaW5nIHRvIGFjY2VwdCwgYW5kIGJlZm9yZSB0aGUgc2VydmVyIGhhcyBhbnkgY2hhbmNl IHRvDQoNCiAgICBhZHZlcnRpc2UgaXRzIG93biBtYXhpbXVtIHJlY29yZCBzaXplLiBIb3dldmVy LCBzaW5jZSB0aGUgaW5pdGlhbA0KDQogICAgcmVjb3JkcyBhcmUgdW5wcm90ZWN0ZWQsIGltcGxl bWVudGF0aW9ucyBtYXkgYmUgYWJsZSB0byBwcm9jZXNzDQoNCiAgICBwYXJ0aWFsIHJlY29yZHMs IGFuZCB0aHVzIGNvdWxkIGFjY2VwdCB1bi1NQUNlZCByZWNvcmRzIGxhcmdlcg0KDQogICAgdGhh biB0aGVpciBpbmNvbWluZyBidWZmZXIgKGF0IGxlYXN0IEJlYXJTU0wgY2FuIGRvIHRoYXQpLg0K DQoNCg0KDQoNClRoZSAiaW1wbGljaXQiIGJlaGF2aW91ciAoYm90aCBmb3IgY2xpZW50IGFuZCBz ZXJ2ZXIpIHdpdGggVExTIDEuMyBpcyBhIHdheSB0byBtYWtlIHRoZSBleHRlbnNpb24gZnJlZSAo d2l0aCByZWdhcmRzIHRvIG5ldHdvcmsgdXNhZ2UpIGluIHRoZSBjb21tb24gY2FzZS4gSXQgY2Fu bm90IGJlIGFwcGxpZWQgdW5sZXNzIHRoZSBleHRlbnNpb24gc3VwcG9ydCBpcyBtYWRlIG1hbmRh dG9yeSBmb3IgVExTIDEuMy4gTWFraW5nIGl0IG1hbmRhdG9yeSBpcyBhbHNvIGFuIGltcG9ydGFu dCBmZWF0dXJlLCBzaW5jZSBvdGhlcndpc2Ugc3VjaCBhbiBleHRlbnNpb24gd291bGQgbGlrZWx5 IHJlbWFpbiB1bmltcGxlbWVudGVkIGJ5ICJiaWciIGNsaWVudHMgKGUuZy4gV2ViIGJyb3dzZXJz KS4NCg0KDQoNCg0KDQpBbnkgY29tbWVudHM/DQoNCkkgY2FuIHRyeSB0byB3cml0ZSB0aGUgY29y cmVzcG9uZGluZyB0ZXh0IGZvciBpbmNsdXNpb24gaW4gdGhlIFRMUyAxLjMgZHJhZnQuIFdoYXQg aXMgdGhlIHByb2Nlc3MgZm9yIHN1Ym1pdHRpbmcgc3VjaCB0ZXh0Pw0KDQoNCg0KDQoNCiAgICAg IC0tVGhvbWFzIFBvcm5pbg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX18NCg0KVExTIG1haWxpbmcgbGlzdA0KDQpUTFNAaWV0Zi5vcmc8bWFpbHRv OlRMU0BpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90 bHMNCg== --_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1913EACBLREML509MBXchi_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: quoted-printable

Hi Thomas

 

Your idea of defining a new similar extension is = the only choice for us. Because as per existing max_fragment_length extensi= on in RFC 6066, client should fail if it receives different value from serv= er.

And also your idea of making the new extension as= mandatory for TLS1.3 is good, as it will be more useful for constraint ser= ver.

 

Earlier in our team also we were discussing about= defining new extension specially for constraint client and server. I sugge= st we should include the below points for new fragment length extension

      1) As per RFC 6066= , if 512 is negotiated then both entity should keep buffer of size 805 byte= s (5 byte - record header, 512 bytes - data, 256 bytes - padding, 32 bytes = - MAC). I think we should change this in our new fragment extension. If 512 is negotiated then both entity should not send any [D]TLS record of= size more than that (includes record header and payload).  Because th= e control overhead of 256 bytes padding and 32 bytes MAC are not applicable= for recent AEAD algorithms. That too in AES_CCM there is no need of padding.

      2) Currently least= value supported by max_fragment_length is 512. I prefer we should add supp= ort for 256 and 128 also. If AES_CCM_8 is used, the control overhead on app= lication record is 21 bytes (5 byte - record header, 8 byte - IV and 8 byte - MIC). If its DTLS record, overhead is 29 bytes. So if ma= x fragment length is 128, we get 99 bytes for data. This is more than suffi= cient for a constraint protocol like CoAP.

      Note : Existing ma= x_fragment_length extension cannot be extended to support new values like 1= 28 and 256.

      3) If a client sen= ds both old and new extension, then priority should be given to new extensi= on. Server MUST not send both the extension.

 

I feel the current IoT world needs this kind of n= ew extension. This is the time to do.

 

Regards,

Ashok

 

Raja Ashok VK
=BB=AA=CE=AA=BC=BC=CA=F5=D3=D0=CF=DE=B9=AB=CB=BE Huawei Technologie= s Co., Ltd.
3D"Company_logo"

Phone:
Fax:
Mobile:
Email:
=B5=D8=D6=B7=A3=BA=C9=EE=DB=DA=CA=D0=C1=FA=B8=DA=C7=F8=DB=E0=CC= =EF=BB=AA=CE=AA=BB=F9=B5=D8 =D3=CA=B1=E0=A3=BA518129
Huawei Technologies Co., Ltd.
Bantian, Longgang District,Shenzhen 518129, P.R.China
http://www.huawei.com

=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC= =D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF= =DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4= =B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB
=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=BD= =CA=B9=D3=C3=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2= =BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9= =B1=BE=D3=CA=BC=FE=D6=D0
=B5=C4=D0=C5=CF=A2=A1=A3=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE= =D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD= =A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
This e-mail and its attachments contain confide= ntial information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!

 

 

-----Original Message-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Thomas Pornin
Sent: 30 November 2016 00:25
To: Fossati, Thomas (Nokia - GB)
Cc: tls@ietf.org
Subject: Re: [TLS] Maximum Fragment Length negotiation

 

On Thu, Nov 24, 2016 at 09:10:00PM +0000, Fos= sati, Thomas (Nokia - GB)

wrote:

> I like your proposal, but I'm not convinced = that overloading the

> semantics of an already existing extension w= hen used in combination

> with a specific version of the protocol is n= ecessarily the best

> strategy.  Besides, I'd like to be able= to deploy a similar mechanism

> in 1.2.

 

Defining a new extension is certainly possible. H= owever, it would then require deciding on the intended behaviour when both = that new extension and the RFC 6066 extension are present.

 

Tentatively, one could try this:

 

  - The new extension documents the maximum = record length supported

    by whoever sends it. Encoding = is as in RFC 6066: one byte of

    value x for a maximum record p= laintext length of 2^(x+8) bytes).

    We extend that to the whole 1.= .8 range so that larger records

    may be used by implementations= who can afford them and obtain

    some performance increase by d= oing so (actual maximum plaintext

    length will be slightly less t= han 65535 bytes becose the length

    header is 16-bit and there mus= t be some room for the MAC).

 

  - If a client sends both the RFC 6066 exte= nsion and the new extension,

    and the server supports the ne= w extension, then the RFC 6066

    extension is ignored and only = the new extension is used. A server

    MUST NOT send both extensions.=

 

  - All implementations that support the ext= ension MUST have the

    ability to apply a shorter siz= e limit than their maximum limit

    (this is for _sending_ records= ).

 

  - The length sent by the server is the one= that will be applied to

    subsequent records on the conn= ection, in both directions. This

    applies to the whole connectio= n, including subsequent handshakes

    (renegotiations), unless both = client and server send the new

    extension again in a renegotia= tion (in which case the new length

    appplies).

 

  - If using TLS 1.3, then the following ext= ra rules apply:

 

     - All TLS 1.3 implementa= tions MUST support the extension.

 

     - If the client does not= send the new extension, then this is

       equivalent t= o the client sending the new extension with a

       value of 6 (= i.e. maximum plaintext length is 2^14 =3D 16384 bytes).

       In particula= r, this allows the server to send the extension.

 

     - If the server does not= send the new extension, then this is

       equivalent t= o the server sending the new extension with the

       same value a= s the one from the client. (So, if neither sends

       the extensio= n, then the usual 16384-byte limit applies.)

 

  - If using TLS 1.2 or a previous version, = then there is no implicit

    usage:

 

     - The server MUST NOT se= nd the new extension unless the client sent

       it.

 

     - The maximum plaintext = limit shall be enforced only if the server

       sent the ext= ension; that limit is the one defined by the server's

       extension.

 

     - If the client and/or t= he server does not send the extension, then

       the maximum = plaintext length is the one that was in force at that

       point, i.e. = 16384 bytes for a new connection, or whatever was

       used before = the new handshake in case of renegotiation.

 

Some noteworthy points:

 

  * TLS 1.3 has no renegotiation, so the ren= egotiation behaviour is

    for TLS 1.2 and previous. This= avoids tricky issues with the

    TLS 1.3 implicit behaviour in = case of renegotiation.

 

  * A client SHOULD send the new extension i= n all ClientHello if it

    is ready to use TLS 1.2 or pre= vious, so that a non-1.3-aware

    server may have the possibilit= y to negotiate a shorter maximum

    plaintext length.

 

  * The initial ClientHello may use records = larger than what the server

   is willing to accept, and befor= e the server has any chance to

    advertise its own maximum reco= rd size. However, since the initial

    records are unprotected, imple= mentations may be able to process

    partial records, and thus coul= d accept un-MACed records larger

    than their incoming buffer (at= least BearSSL can do that).

 

 

The "implicit" behaviour (both for clie= nt and server) with TLS 1.3 is a way to make the extension free (with regar= ds to network usage) in the common case. It cannot be applied unless the ex= tension support is made mandatory for TLS 1.3. Making it mandatory is also an important feature, since otherwise such an = extension would likely remain unimplemented by "big" clients (e.g= . Web browsers).

 

 

Any comments?

I can try to write the corresponding text for inc= lusion in the TLS 1.3 draft. What is the process for submitting such text?<= o:p>

 

 

      --Thomas Pornin

 

_______________________________________________

TLS mailing list

TLS@ietf.org

https://www.ietf= .org/mailman/listinfo/tls

--_000_FDFEA8C9B9B6BD4685DCC959079C81F5E1913EACBLREML509MBXchi_-- --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1913EACBLREML509MBXchi_ Content-Type: image/jpeg; name="image001.jpg" Content-Description: image001.jpg Content-Disposition: inline; filename="image001.jpg"; size=6737; creation-date="Wed, 30 Nov 2016 10:48:49 GMT"; modification-date="Wed, 30 Nov 2016 10:48:49 GMT" Content-ID: Content-Transfer-Encoding: base64 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --_004_FDFEA8C9B9B6BD4685DCC959079C81F5E1913EACBLREML509MBXchi_-- From nobody Wed Nov 30 05:25:45 2016 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 585A812987B for ; Wed, 30 Nov 2016 05:25:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.399 X-Spam-Level: X-Spam-Status: No, score=-8.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 L8LC36YO7_Oi for ; Wed, 30 Nov 2016 05:25:43 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3F2812989B for ; Wed, 30 Nov 2016 05:22:25 -0800 (PST) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 902A431B32C; Wed, 30 Nov 2016 13:22:25 +0000 (UTC) Received: from pintsize.usersys.redhat.com (dhcp-0-115.brq.redhat.com [10.34.0.115]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uAUDMNsS027194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 30 Nov 2016 08:22:25 -0500 From: Hubert Kario To: tls@ietf.org Date: Wed, 30 Nov 2016 14:22:17 +0100 Message-ID: <2592774.mFcuq1jeh1@pintsize.usersys.redhat.com> User-Agent: KMail/5.3.2 (Linux/4.8.8-200.fc24.x86_64; KDE/5.27.0; x86_64; ; ) In-Reply-To: References: <20161124195002.GA32346@bolet.org> <20161129185451.GA4541@bolet.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2930380.bCDdgpxlce"; micalg="pgp-sha512"; protocol="application/pgp-signature" X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Wed, 30 Nov 2016 13:22:25 +0000 (UTC) Archived-At: Subject: Re: [TLS] Maximum Fragment Length negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Nov 2016 13:25:44 -0000 --nextPart2930380.bCDdgpxlce Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote: > On 30 November 2016 at 05:54, Thomas Pornin wrote: > > Any comments? >=20 > I'm ambivalent on this generally: though I think that the general > notion is OK, I'm not sure about the details. >=20 > In particular, you need to be clearer in your motivations: the point > is to ensure that little things (really little things) can talk to any > other TLS implementation. That seems inherently good, but it might > pay to dig into that some more: why is that good? because if they can't use TLS, they will create a bespoke protocol, and tho= se=20 have a tendency of being completely broken, on conceptual level, let alone= =20 implementation combine it with the fact that "trusted network" doesn't exist any more and = you=20 end up with solutions that are insecure with nobody using them knows they a= re=20 insecure, especially in IoT space =2D-=20 Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic --nextPart2930380.bCDdgpxlce Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAABCgAGBQJYPtKJAAoJEJKo0bgB0vX1BpIP/ArWt2F2Qdn3Z6z4IGW3JkWe F99MkSPD1KyARgh+bzwa/FWt+q6w0aKSh+9c4670ndbfm3grojQoAOAthPiNGl3P VHz43d1DgfKeycYpYIuiCR0WIYfYsEO+mJKtB4x0584ekP4ogf9K+SNlNnN7jWh5 IHogtkgjGZDfhMT4cqasDizDEZ+kQ40le98bKoH4BrNYB0dzkJHmRihPFWmbkyPM 0T+J3Etuf9kf8rCbV5tDjHiVX7vQ5/3cPFtEkVcncEBWgkj9Qqq5multnN0zZzwO 46XTT/ufWND1qBxAP3Jy5tYf95hJF1TY+HfU8CgZ0yIedFyMHbetz+WPQDRPXNEb 3LQmXpgSIVURXPpayk1LFBUbwOhWhhZQylnlrl7hyOADeQBvMuwEhlJZfDkJyGbP q4I3p62Yu0kY0zlT3WE1O7OJKb9qdBdoxGwzH3HCL6XIThvd+9VWPvAnsWOEj7M2 JHUlR0t1r9EHvW2lD6iC31QElertk7qaJVB4NyvOFoucHBeyG0upnKibCQyr+GxQ lczw6xjjMLkn54yoU8wyIbe6Ra8abMzWvAUxF5fi5MOmq+qat5v4ULbUzRbqs9Ho k/3+nsakPdj3cQNYAdMOSZcWUuTSLqvRwv5YK/KMt1hntCRnzFgrLpHzDUZzLrnD pXn+D3QPEpsx80LiP7CB =TJN3 -----END PGP SIGNATURE----- --nextPart2930380.bCDdgpxlce-- From nobody Wed Nov 30 06:42:19 2016 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 BD7DF129526 for ; Wed, 30 Nov 2016 06:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 mfzG_GyjKp0h for ; Wed, 30 Nov 2016 06:42:15 -0800 (PST) Received: from mail-yb0-x22a.google.com (mail-yb0-x22a.google.com [IPv6:2607:f8b0:4002:c09::22a]) (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 844681294E6 for ; Wed, 30 Nov 2016 06:42:15 -0800 (PST) Received: by mail-yb0-x22a.google.com with SMTP id v132so17416998yba.0 for ; Wed, 30 Nov 2016 06:42:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=sRgvIT3N7hDpv5mOt3Cj8faJjcDcOokKwakUsD5aL8Q=; b=0aL/bWjy/ViroItKQmjsYvjyqttfdpwpljAvRjKJstHfquvDagqU63OtgpqulJNpLj PQkUlDfLxWcGTtRQu1nfukyuYXOu84R9oseXVerB7bHYnTI7BqHUCy+QqKXAeyWeXQue GDBWi525b1mlN/fY98WUZCNOWmfQRWpqYnhCI1czOKHDroZ49kUf7zLCsW/Fj/5DwEwF ILQftzou5o2FXuss0sEU3IUxkR63VfRsNO6K98Gl0npVTkiHo8pBKc+Y5PIS6XcE6XKU HpBTRAHgZ4NDEhzJQobM+52HY1M8uZIYIA/fWQVTZO2nhVsrbl4dEiMddRwCd/sC/lf1 XQiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=sRgvIT3N7hDpv5mOt3Cj8faJjcDcOokKwakUsD5aL8Q=; b=YWUh3wYiVw43Kw4Wdvq3UH9G/bcdYwapGs/PvblfEt27FcdN9ltRz/fQeDpC3HMtQA 7PvmepqNyygzTrsjISGCDVTr7BNRTksa0GCjbRvGt6z4IhNnZAniBBWpxp9z8KB9ne5Y rITr3b9qAR3fiVu+KhmLCNoGwmjTvGsVktO3G+9s0uEtOZQpKoqpTmuk2k/l9HzNKsGk 225+SnWC74Kl7vCcCBnWlbnIW2ul7hy36gBR8C2uUydmCn8pXGv3nqQRLc+tOyawkgmr Vp05/3V4PkmcAYQr/KPNyRzyW8zgQg2jse/djTWTtsGwScs/B/5nrXjoUIzU5gV18zV7 c+UA== X-Gm-Message-State: AKaTC00MEzlXzvM1TnuR8jK+lAD37bgs8wY9u4cLyVwG65jQQkIAYGKYjB4KbUD+NTT7lp2T3TnwN0qyml19ZA== X-Received: by 10.37.162.1 with SMTP id b1mr8090982ybi.80.1480516934358; Wed, 30 Nov 2016 06:42:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Wed, 30 Nov 2016 06:41:33 -0800 (PST) From: Eric Rescorla Date: Wed, 30 Nov 2016 09:41:33 -0500 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c19ffd6f52741054285b5e2 Archived-At: Subject: [TLS] PR#800: Clarify supported versions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Nov 2016 14:42:18 -0000 --94eb2c19ffd6f52741054285b5e2 Content-Type: text/plain; charset=UTF-8 https://github.com/tlswg/tls13-spec/pull/800 In Seoul we had rough consensus (or at least apathy) to leave the supported versions semantics alone but tighten up the language. The above PR does that. One point I notice we didn't discuss is whether we should require the server to check that ClientHello.legacy_version == 0303. NSS (and I believe BoringSSL) currently ignore it which i believe is the best reading of -18 and is what is in this PR. I think if we're going to change this we should just make it an error to have supported_versions and legacy_version != 0303. My preference would be to leave as-is, however. -Ekr --94eb2c19ffd6f52741054285b5e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
h= ttps://github.com/tlswg/tls13-spec/pull/800

In S= eoul we had rough consensus (or at least apathy) to leave the supported ver= sions
semantics alone but tighten up the language. The above PR d= oes that.

One point I notice we didn't discuss= is whether we should require the server to check
that ClientHell= o.legacy_version =3D=3D 0303. NSS (and I believe BoringSSL) currently
=
ignore it which i believe is the best reading of -18 and is what is in= this PR.

I think if we're going to change thi= s we should just make it an error to have
supported_versions and = legacy_version !=3D 0303. My preference would be to leave
as-is, = however.

-Ekr

--94eb2c19ffd6f52741054285b5e2-- From nobody Wed Nov 30 07:34:06 2016 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 934811295B0 for ; Wed, 30 Nov 2016 07:34:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 zz73MIfENNER for ; Wed, 30 Nov 2016 07:34:01 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 8A2AC129696 for ; Wed, 30 Nov 2016 07:33:39 -0800 (PST) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9226643341B; Wed, 30 Nov 2016 15:33:38 +0000 (GMT) Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 7A20C4EA13; Wed, 30 Nov 2016 15:33:38 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1480520018; bh=6ZKJIwJop2A39JzS3GqWNfJeI+llGsnb9cPwdCIrlxI=; l=460; h=From:To:Date:References:In-Reply-To:From; b=V6e+miyM7orO09GbXmPHO02B9vtEjMdY8dDC1QQq+3+poHbz6cU8Kw1efG13K5ahS nczs39NZioHgDE7OMFpE0PJhOARbPdf1CmBSPAbw9x5hDlc6ojVV0LXpBDWxNIu4sf 4d4mfTtHD2vgFlJ0nvp2uTdtXzV2VKJ2KBxewEeU= Received: from email.msg.corp.akamai.com (usma1ex-casadmn.msg.corp.akamai.com [172.27.123.33]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 6E87A1FC8C; Wed, 30 Nov 2016 15:33:38 +0000 (GMT) Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com (172.27.123.101) by usma1ex-dag1mb1.msg.corp.akamai.com (172.27.123.101) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Wed, 30 Nov 2016 10:33:38 -0500 Received: from USMA1EX-DAG1MB1.msg.corp.akamai.com ([172.27.123.101]) by usma1ex-dag1mb1.msg.corp.akamai.com ([172.27.123.101]) with mapi id 15.00.1178.000; Wed, 30 Nov 2016 10:33:38 -0500 From: "Salz, Rich" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] PR#800: Clarify supported versions Thread-Index: AQHSSxf3vf99Seg8dkKK4oSdgs3I4qDxp8xQ Date: Wed, 30 Nov 2016 15:33:37 +0000 Message-ID: <5499f5b450cf47d9969be117d8c41e2f@usma1ex-dag1mb1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [172.19.35.197] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] PR#800: Clarify supported versions X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Nov 2016 15:34:04 -0000 PiAgSSB0aGluayBpZiB3ZSdyZSBnb2luZyB0byBjaGFuZ2UgdGhpcyB3ZSBzaG91bGQganVzdCBt YWtlIGl0IGFuIGVycm9yIHRvIGhhdiBzdXBwb3J0ZWRfdmVyc2lvbnMgYW5kIGxlZ2FjeV92ZXJz aW9uICE9IDAzMDMuIE15IHByZWZlcmVuY2Ugd291bGQgYmUgdG8gbGVhdmUgYXMtaXMsIGhvd2V2 ZXIuDQoNCkkgdGhpbmsgbWFraW5nIGl0IGEgTVVTVCBOT1QgaXMgZW5vdWdoIGFuZCBnaXZlcyB0 aGUgc2VydmVyIGZyZWVkb20gdG8gZG8gd2hhdCBpdCB3YW50cywgaW5jbHVkaW5nIGh1bnQgZG93 biBhbmQgZm9yY2libHkgdXBncmFkZSB0aGUgY2xpZW50IHNvZnR3YXJlLi4uDQoNCg0K From nobody Wed Nov 30 09:54:55 2016 Return-Path: X-Original-To: tls@ietf.org Delivered-To: tls@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 56929129951; Wed, 30 Nov 2016 09:54:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: , , X-Test-IDTracker: no X-IETF-IDTracker: 6.39.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148052849435.9690.14319448678983267998.idtracker@ietfa.amsl.com> Date: Wed, 30 Nov 2016 09:54:54 -0800 Archived-At: Subject: [TLS] The TLS WG has placed draft-thomson-tls-tls13-vectors in state "Candidate for WG Adoption" X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Nov 2016 17:54:54 -0000 The TLS WG has placed draft-thomson-tls-tls13-vectors in state Candidate for WG Adoption (entered by Sean Turner) The document is available at https://datatracker.ietf.org/doc/draft-thomson-tls-tls13-vectors/ From nobody Wed Nov 30 14:16:26 2016 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 1D70C12959F for ; Wed, 30 Nov 2016 14:16:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no 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 Yu6y28GtZW-a for ; Wed, 30 Nov 2016 14:16:21 -0800 (PST) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91C812952B for ; Wed, 30 Nov 2016 14:16:21 -0800 (PST) Received: from [47.143.125.162] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1cCDAl-0002r1-Iv for tls@ietf.org; Wed, 30 Nov 2016 17:16:15 -0500 Date: Wed, 30 Nov 2016 14:16:15 -0800 From: Bill Frantz To: tls@ietf.org X-Priority: 3 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.4 (470) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec797acca4f4cc53882463862fea539ceefd350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 47.143.125.162 Archived-At: Subject: Re: [TLS] Certificate compression (a la QUIC) for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Nov 2016 22:16:24 -0000 On 11/29/16 at 5:28 AM, rsalz@akamai.com (Salz, Rich) wrote: >Sure, here's my compressed cert. Ignore the fact that it's named "42.zip" = -- see https://en.wikipedia.org/wiki/Zip_bomb > >The risks of uncompressing data sent from a counterparty who has not yet b= een authenticated, do not outweigh the gains. There is a long history of successful attacks on systems through=20 zip decompressors. In general, adding complexity to a security system makes it=20 harder to understand, easier to compromise and less secure. If the problem is that certificates are too big, fix that=20 problem at the source. Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | Privacy is dead, get over | Periwinkle (408)356-8506 | it. | 16345=20 Englewood Ave www.pwpconsult.com | - Scott McNealy | Los Gatos,=20 CA 95032 From nobody Wed Nov 30 14:43:59 2016 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 581B6129BAF for ; Wed, 30 Nov 2016 14:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLTdd3JGeYYp for ; Wed, 30 Nov 2016 14:43:55 -0800 (PST) Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 A50AC129BA9 for ; Wed, 30 Nov 2016 14:43:55 -0800 (PST) Received: by mail-qt0-x232.google.com with SMTP id n6so203646485qtd.1 for ; Wed, 30 Nov 2016 14:43:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=+rWoO3cAEZG/9rLxggOVEjFcl/zs1kVujR5jqYK2wT0=; b=MJG5U4qXbllsDC/s8KS4ILtUJVtjpPsrL5Lnkbvpqis4IxkuShD+zNYjN3mdszE0pB Xpn/MUpSI1A5IiUeQaHdj2Hi9bTh/7hsWe9cMTa0WD64w9ZveG6AZaI6eRBc8SfSNe4b FCj5gKRTF4v7fyncJqZmFFMJTY/6SLHHLnY4wB4/C55CjmhmAKXwgyHzXgICAIlhhICu avk8cfh04c3Lhx6x4srbaBD9/RK9KpCZAsBUSHRekEAYZuZuN9AcDEtDp6xZMLOwu3cS 8nhb3xGW4SHu8aCAtYQ6VVv4oiVagshCx81dgYyWnDeTpjAFKCZuwUOcf9p7PwVpMyDL 4w/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=+rWoO3cAEZG/9rLxggOVEjFcl/zs1kVujR5jqYK2wT0=; b=H9H3wJ3F+e4TS3SE4BgjKtqWWaaCdo2AX2wkV/9UOsbB1xS3mLN5k+QUFNM1lzB3rA R14tC7lr2mS0O6TM3UH5LVzo5VkpuVKO9luaRM/kiRMGtyJDsHQka84MzB9CREvkPwWH IpBy3AkhrrsfAJzyLZC0TsJAlchIybMamGhNW3mymgjIPm0o7Jn+rkfkFyN374Hqy4p1 tIvF+A2EW+KKeoOrKONBZTS1GWDfDS7/3FPfmtobcLzeTZQTG+nJDltVdl5Ypcx4H80n h8FhfnpnR0FrTJvlIjo4ldmQsii4jn55HeTO51ruunCupZcjC6JZTZR0LEwLkBnAdhDf O9QQ== X-Gm-Message-State: AKaTC03cB8oEim2Y15mf6dZMdy88Cuq7SUoS6iC5JvGIl/Dv6Vhf26OUm6CLdxDo2TxSh6P4o41pgoT0GvF0Yg== X-Received: by 10.200.35.14 with SMTP id a14mr31010246qta.159.1480545834834; Wed, 30 Nov 2016 14:43:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.140.38.233 with HTTP; Wed, 30 Nov 2016 14:43:54 -0800 (PST) In-Reply-To: <2592774.mFcuq1jeh1@pintsize.usersys.redhat.com> References: <20161124195002.GA32346@bolet.org> <20161129185451.GA4541@bolet.org> <2592774.mFcuq1jeh1@pintsize.usersys.redhat.com> From: Martin Thomson Date: Thu, 1 Dec 2016 09:43:54 +1100 Message-ID: To: Hubert Kario Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: "tls@ietf.org" Subject: Re: [TLS] Maximum Fragment Length negotiation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Wed, 30 Nov 2016 22:43:57 -0000 Asking ALL TLS implementations to change to accommodate these things is a pretty blunt instrument. I want to be sure that this is necessary. (FWIW, I think that this is a reasonable request, I would probably be OK with a smaller maximum by default even.) On 1 December 2016 at 00:22, Hubert Kario wrote: > On Wednesday, 30 November 2016 11:20:01 CET Martin Thomson wrote: >> On 30 November 2016 at 05:54, Thomas Pornin wrote: >> > Any comments? >> >> I'm ambivalent on this generally: though I think that the general >> notion is OK, I'm not sure about the details. >> >> In particular, you need to be clearer in your motivations: the point >> is to ensure that little things (really little things) can talk to any >> other TLS implementation. That seems inherently good, but it might >> pay to dig into that some more: why is that good? > > because if they can't use TLS, they will create a bespoke protocol, and t= hose > have a tendency of being completely broken, on conceptual level, let alon= e > implementation > > combine it with the fact that "trusted network" doesn't exist any more an= d you > end up with solutions that are insecure with nobody using them knows they= are > insecure, especially in IoT space > -- > Regards, > Hubert Kario > Senior Quality Engineer, QE BaseOS Security team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic From nobody Wed Nov 30 16:25:15 2016 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 9FE06129BE7 for ; Wed, 30 Nov 2016 16:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.20150623.gappssmtp.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 72wwhiaFt8Iw for ; Wed, 30 Nov 2016 16:25:08 -0800 (PST) Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 9CDBC1295B4 for ; Wed, 30 Nov 2016 16:25:07 -0800 (PST) Received: by mail-io0-x22f.google.com with SMTP id j65so383399835iof.0 for ; Wed, 30 Nov 2016 16:25:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=+/78GAVSinJadlF7nsiWwj1GsXvtUAzQwacqUfAqKQ8=; b=vjYIbplUS1y/r9iNDRftS2qWzlvyyrtA9eKLEFW4VvAVU6mWrGPorGysCbbIwJQaU+ CfzV77SJ9sP/ZWTS172etYKqnP7/bz+8vCqJXTfp3XOx3Yg3QboIKNz3D7CUdSAApazZ AZqRHwpvVGN4nwhEXZZ0GzFlzHFU/iK7Fokzd7O/sQQ43O7TUndAj42UReQmDN+JMT/J VmYZe5hF7380l6uJGTD+JTP+zyc1cU8/nOS3NUHcfGCL3Ye9iA+9uB5LGwgRP4u1cBLw kQTaqfPMpyDNqsoHo5WoMKYwyDlL3REZ+vF+YNr7HssumQGjdXv1JGvv92130S7h6wy1 JY8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+/78GAVSinJadlF7nsiWwj1GsXvtUAzQwacqUfAqKQ8=; b=Y2bmDV/PNxBOIq86S61VC/7gEt8cPEfGI0ZbB6RkGSdPw+/mZdmU0zzZl9QndWGdgz /pt/DLJL15Owbit0Ko+WQ8OwEbRWm842DfGleCeuq//ajqy8kag5JNJdUHLLRSvRFtZz PGp8RQFt7VFjLKgnYcVK7gN1oOdUF/LYtgd/39H5QTOie1kvLLnvG1GbXXTLnF1DCvNS cxbrwL4vKhotElx63TpSL02EXyoMKqZaEuI0H38sC5xza78JTG3oJTiHFNHF4XQ+4M4i 4GxxttlmuSmPdjKsfTvR2ivkITMJMIkeIQUtP5em8ya/OF3s66uguzjVDP2eXPn7kzcJ JEoA== X-Gm-Message-State: AKaTC03L5MDqlWF5s7XHhsJdWKWBIdQM/P7NQM1EJNDgE175yMWCbKVe5GKNeZ8/iAbhNP/8yl//vMsJdCXAGQ== X-Received: by 10.36.219.196 with SMTP id c187mr31262370itg.23.1480551906622; Wed, 30 Nov 2016 16:25:06 -0800 (PST) MIME-Version: 1.0 Received: by 10.79.35.224 with HTTP; Wed, 30 Nov 2016 16:24:46 -0800 (PST) From: Joseph Salowey Date: Wed, 30 Nov 2016 16:24:46 -0800 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=94eb2c05f1d8775bd605428dda16 Archived-At: Subject: [TLS] Draft meeting minutes X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 01 Dec 2016 00:25:11 -0000 --94eb2c05f1d8775bd605428dda16 Content-Type: text/plain; charset=UTF-8 I uploaded draft meeting minutes form the Seoul meeting to the proceedings ( https://www.ietf.org/proceedings/97/minutes/minutes-97-tls-00.txt). Thanks to Jim Schaad for taking minutes. Let me know if you have corrections. Cheers, Joe --94eb2c05f1d8775bd605428dda16 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I uploaded draft meeting minutes form the Seoul meeting to= the proceedings (https://www.ietf.org/proceedings/97/minutes/minutes-97= -tls-00.txt).=C2=A0 Thanks to Jim Schaad for taking minutes. =C2=A0
Let me know if you have corrections.=C2=A0

Cheers,

Joe
--94eb2c05f1d8775bd605428dda16-- From nobody Wed Nov 30 17:47:08 2016 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 99341129500 for ; Wed, 30 Nov 2016 17:47:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, T_KAM_HTML_FONT_INVALID=0.01] 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XHIPaDBfCgvB for ; Wed, 30 Nov 2016 17:47:01 -0800 (PST) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::22e]) (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 DA3BE127A90 for ; Wed, 30 Nov 2016 17:47:00 -0800 (PST) Received: by mail-ua0-x22e.google.com with SMTP id 12so233284398uas.2 for ; Wed, 30 Nov 2016 17:47:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=93LThPwDOcYi90XENOYzFRJs1M3rS5XVQRQcehEgi7s=; b=S7GKH3nDU1RVP/APmxL+po7w9b7OLAEFm2scNWiWfDm4Ifn9BrYHn/hZQpWksNx2Ma 7vNWk5b+vqz27vpl7gifbyq65uo/llLDZJxh7XHzcdpCynuOIguK+Ln4Lnto89g4SM/h 2nKvT6UjTzkCslyMscMtmKuODL7kNkytxWSia4yYv1/RVph1M4tpZ6XtHMAcfVrywF+K s5Ct9fyzJ/JjQyx8Oo3Aq6aEJe19Q37VW/Gvr/WDxl3W6qKV8/43gJmb2XluAQv900vb /nIngUWcpDLUUo5MGpwFrPCKhVqWUNlu34joRMMI2t5AVamhOChq1lIcQCb6seCjaZTP zXoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=93LThPwDOcYi90XENOYzFRJs1M3rS5XVQRQcehEgi7s=; b=CPEkA0z6VTOXA5xpuCBTOS2EGuOXZ844z/5Zd4JSuOvS5qvtYjLPggZHH5+mqeDysM tdDhIP7I6IYms6OTGcTZH5TH+pv6gDBmWgrS93If6y+VqzCO6fplGvw4tzwOWpgj8cOM ArlURQZCn7gYYTImqv1b4hvQkbk+V7optmuLUNwbN52EcHegu6EDz4LTYyaGXyikozK1 +Xl5wA2M9GVYtZuyGPrjwCHx3edAbz5fwjg0VCIHAdXDPgq8q5NZx4dqPHqdzlAQ6MsL 3BkHbEIigXHcrAITTXCN63PtrmDtKKZIutqUPih6ytHAgFnUIXrhCFe4p+QpGdXMO89l 4l6A== X-Gm-Message-State: AKaTC02na3K139RqpsGPkIJbHe2+cAp0HTIuue/pRsocTk1egdgFNg723Xy2DTZdw5F4ZqZPATNFFG34nOAmHw== X-Received: by 10.159.48.221 with SMTP id k29mr28498557uab.53.1480556819670; Wed, 30 Nov 2016 17:46:59 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Thu, 01 Dec 2016 01:46:47 +0000 Message-ID: To: "" Content-Type: multipart/related; boundary=f403045dd1804e92d905428eff0f Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 01 Dec 2016 01:47:03 -0000 --f403045dd1804e92d905428eff0f Content-Type: multipart/alternative; boundary=f403045dd1804e92d705428eff0e --f403045dd1804e92d705428eff0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I took a very unofficial Twitter poll on this subject: https://twitter.com/grittygrease/status/803644086666215424 Nick On Tue, Nov 29, 2016 at 5:47 AM Raja ashok wrote: > I feel we can go ahead with TLS 1.3. > > Or else TLS 3.4, because anyway we send 0x0304 on wire for TLS 1.3. > > > > I hope all other three options (TLS 2.0, TLS 2 and TLS 4) will make > confusion with SSL versions for end user. > > > ------------------------------ > > Raja Ashok VK > =E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8 = Huawei Technologies Co., Ltd. > [image: image001.jpg] > > Phone: > Fax: > Mobile: > Email: > Huawei Technologies Co., Ltd. > Bangalore, India > > http://www.huawei.com > ------------------------------ > > =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB= =E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4= =BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB= =99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84= =E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81 > =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB= =E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4= =BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88= =86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96= =E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD > =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99= =E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7= =AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F= =A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE= =E4=BB=B6=EF=BC=81 > This e-mail and its attachments contain confidential information from > HUAWEI, which > is intended only for the person or entity whose address is listed above. > Any use of the > information contained herein in any way (including, but not limited to, > total or partial > disclosure, reproduction, or dissemination) by persons other than the > intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > > > > > -----Original Message----- > From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sean Turner > Sent: 18 November 2016 07:43 > To: > Subject: [TLS] Confirming consensus: TLS1.3->TLS* > > > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-p= r612-01.pdf > . > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. > > > > Thanks, > > J&S > > _______________________________________________ > > 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 > --f403045dd1804e92d705428eff0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I took a very unofficial Twitter poll on this subject= :
https://twitter.com/grittygrease/status/803644086666215424
<= br>
Nick

On = Tue, Nov 29, 2016 at 5:47 AM Raja ashok <raja.ashok@huawei.com> wrote:

I feel we can go = ahead with TLS 1.3. <= /p>

Or else TLS 3.4, = because anyway we send 0x0304 on wire for TLS 1.3.

=C2=A0

I hope all other = three options (TLS 2.0, TLS 2 and TLS 4) will make confusion with SSL versi= ons for end user.

=C2=A0

Raj= a Ashok VK
=E5=8D=8E=E4=B8=BA=E6=8A=80=E6= =9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8 Huawei Technologies Co., Ltd.



Phone:
Fax:
Mobile:
Email:
Huawei Technologies Co., Ltd.
Bangalore, India

http:/= /www.huawei.com

=E6=9C= =AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=E5=90=AB=E6=9C=89= =E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=AF=86=E4=BF=A1=E6= =81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=81=E7=BB=99=E4=B8= =8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=E7=9A=84=E4=B8=AA= =E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81
=E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85= =B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF= =E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5= =85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80= =81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC= =E9=82=AE=E4=BB=B6=E4=B8=AD
=E7=9A=84=E4=BF=A1=E6=81=AF=E3=80= =82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE= =E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6= =88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9= =B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=81
This e-mail and its attachm= ents contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. An= y use of the
information contained herein in any way (including, but not limited to, tot= al or partial
disclosure, reproduction, or dissemination) by persons other than the inten= ded
recipient(s) is prohibited. If you receive this e-mail in error, please not= ify the sender by
phone or email immediately and delete it!=

=C2=A0

=C2=A0

-----Original Mes= sage-----
From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Sean Turner
Sent: 18 November 2016 07:43
To: <tls@ietf.org>
Subject: [TLS] Confirming consensus: TLS1.3->TLS*=

=C2=A0

At IETF 97, the c= hairs lead a discussion to resolve whether the WG should rebrand TLS1.3 to = something else.=C2=A0 Slides can be found @ h= ttps://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr61= 2-01.pdf.<= /p>

=C2=A0

The consensus in = the room was to leave it as is, i.e., TLS1.3, and to not rebrand it to TLS = 2.0, TLS 2, or TLS 4.=C2=A0 We need to confirm this decision on the list so= please let the list know your top choice between:

=C2=A0

- Leave it TLS 1.= 3

- Rebrand TLS 2.0=

- Rebrand TLS 2

- Rebrand TLS 4

=C2=A0

by 2 December 201= 6.

=C2=A0

Thanks,

J&S

_________________= ______________________________

TLS mailing list<= u class=3D"gmail_msg">

TLS@ietf.org=

= h= ttps://www.ietf.org/mailman/listinfo/tls<= /u>

_______________________________________________
TLS mailing list
TLS@i= etf.org
https://www.ietf.org/mailman/listinfo/t= ls
--f403045dd1804e92d705428eff0e-- --f403045dd1804e92d905428eff0f Content-Type: image/jpeg; name="image001.jpg" Content-Disposition: inline; filename="image001.jpg" Content-Transfer-Encoding: base64 Content-ID: <158b80f4c4d4ce8e91> X-Attachment-Id: 158b80f4c4d4ce8e91 /9j/4AAQSkZJRgABAQEAYABgAAD/7QxmUGhvdG9zaG9wIDMuMAA4QklNBCUAAAAAABAAAAAAAAAA AAAAAAAAAAAAOEJJTQPtAAAAAAAQAEgAAAABAAIASAAAAAEAAjhCSU0EJgAAAAAADgAAAAAAAAAA AAA/gAAAOEJJTQQNAAAAAAAEAAAAHjhCSU0EGQAAAAAABAAAAB44QklNA/MAAAAAAAkAAAAAAAAA AAEAOEJJTQQKAAAAAAABAAA4QklNJxAAAAAAAAoAAQAAAAAAAAACOEJJTQP1AAAAAABIAC9mZgAB AGxmZgAGAAAAAAABAC9mZgABAKGZmgAGAAAAAAABADIAAAABAFoAAAAGAAAAAAABADUAAAABAC0A AAAGAAAAAAABOEJJTQP4AAAAAABwAAD/////////////////////////////A+gAAAAA//////// /////////////////////wPoAAAAAP////////////////////////////8D6AAAAAD///////// ////////////////////A+gAADhCSU0EAAAAAAAAAgAAOEJJTQQCAAAAAAACAAA4QklNBDAAAAAA AAEBADhCSU0ELQAAAAAABgABAAAABjhCSU0ECAAAAAAAEAAAAAEAAAJAAAACQAAAAAA4QklNBB4A AAAAAAQAAAAAOEJJTQQaAAAAAAM9AAAABgAAAAAAAAAAAAAAIAAAAGYAAAAEAGwAbwBnAG8AAAAB AAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAGYAAAAgAAAAAAAAAAAAAAAAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAAEAAAAAEAAAAAAABudWxsAAAAAgAAAAZib3VuZHNPYmpjAAAAAQAAAAAA AFJjdDEAAAAEAAAAAFRvcCBsb25nAAAAAAAAAABMZWZ0bG9uZwAAAAAAAAAAQnRvbWxvbmcAAAAg AAAAAFJnaHRsb25nAAAAZgAAAAZzbGljZXNWbExzAAAAAU9iamMAAAABAAAAAAAFc2xpY2UAAAAS AAAAB3NsaWNlSURsb25nAAAAAAAAAAdncm91cElEbG9uZwAAAAAAAAAGb3JpZ2luZW51bQAAAAxF U2xpY2VPcmlnaW4AAAANYXV0b0dlbmVyYXRlZAAAAABUeXBlZW51bQAAAApFU2xpY2VUeXBlAAAA AEltZyAAAAAGYm91bmRzT2JqYwAAAAEAAAAAAABSY3QxAAAABAAAAABUb3AgbG9uZwAAAAAAAAAA TGVmdGxvbmcAAAAAAAAAAEJ0b21sb25nAAAAIAAAAABSZ2h0bG9uZwAAAGYAAAADdXJsVEVYVAAA AAEAAAAAAABudWxsVEVYVAAAAAEAAAAAAABNc2dlVEVYVAAAAAEAAAAAAAZhbHRUYWdURVhUAAAA AQAAAAAADmNlbGxUZXh0SXNIVE1MYm9vbAEAAAAIY2VsbFRleHRURVhUAAAAAQAAAAAACWhvcnpB bGlnbmVudW0AAAAPRVNsaWNlSG9yekFsaWduAAAAB2RlZmF1bHQAAAAJdmVydEFsaWduZW51bQAA AA9FU2xpY2VWZXJ0QWxpZ24AAAAHZGVmYXVsdAAAAAtiZ0NvbG9yVHlwZWVudW0AAAARRVNsaWNl QkdDb2xvclR5cGUAAAAATm9uZQAAAAl0b3BPdXRzZXRsb25nAAAAAAAAAApsZWZ0T3V0c2V0bG9u ZwAAAAAAAAAMYm90dG9tT3V0c2V0bG9uZwAAAAAAAAALcmlnaHRPdXRzZXRsb25nAAAAAAA4QklN BCgAAAAAAAwAAAABP/AAAAAAAAA4QklNBBEAAAAAAAEBADhCSU0EFAAAAAAABAAAAAg4QklNBAwA AAAABnAAAAABAAAAZgAAACAAAAE0AAAmgAAABlQAGAAB/9j/4AAQSkZJRgABAgAASABIAAD/7QAM QWRvYmVfQ00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUT ExgRDAwMDAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4O Dg4UEQwMDAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMB IgACEQEDEQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEB AAAAAAAAAAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSR obFCIyQVUsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSF tJXE1OT0pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIR AyExEgRBUWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVV NnRl4vKzhMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEA AhEDEQA/APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC6 6f56f3t30Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUs VaDHl/dl/X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5Vtns U/qp1vqPUvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9 w9+kqfV+qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVh fWLCzerW9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX 146P1azqFWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKeh SWDk/XHpVHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8t bvSU9Ikucy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uo JBeNpMtfRc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxb qtG20uI0PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv /QXjOu9COI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5F ztrrn/usXoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4 HX+6yY/jQHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v 6hNyW9Q6jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m +u1tQc9n0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6 tfRj2YnTgMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJ JT5b0bpfUrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6r WuLnfpNjXu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z OEJJTQQhAAAAAABVAAAAAQEAAAAPAEEAZABvAGIAZQAgAFAAaABvAHQAbwBzAGgAbwBwAAAAEwBB AGQAbwBiAGUAIABQAGgAbwB0AG8AcwBoAG8AcAAgAEMAUwAyAAAAAQA4QklNBAYAAAAAAAcABQAA AAEBAP/hB4ZFeGlmAABJSSoACAAAAAcAEgEDAAEAAAABAAAAGgEFAAEAAABiAAAAGwEFAAEAAABq AAAAKAEDAAEAAAACAAAAMQECABwAAAByAAAAMgECABQAAACOAAAAaYcEAAEAAACiAAAAzAAAAID8 CgAQJwAAgPwKABAnAABBZG9iZSBQaG90b3Nob3AgQ1MyIFdpbmRvd3MAMjAwNzowMjoyNiAxNjox ODo1MwADAAGgAwABAAAA/////wKgBAABAAAAZgAAAAOgBAABAAAAIAAAAAAAAAAGAAMBAwABAAAA BgAAABoBBQABAAAAGgEAABsBBQABAAAAIgEAACgBAwABAAAAAgAAAAECBAABAAAAKgEAAAICBAAB AAAAVAYAAAAAAABIAAAAAQAAAEgAAAABAAAA/9j/4AAQSkZJRgABAgAASABIAAD/7QAMQWRvYmVf Q00AAv/uAA5BZG9iZQBkgAAAAAH/2wCEAAwICAgJCAwJCQwRCwoLERUPDAwPFRgTExUTExgRDAwM DAwMEQwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwBDQsLDQ4NEA4OEBQODg4UFA4ODg4UEQwM DAwMEREMDAwMDAwRDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDP/AABEIACAAZgMBIgACEQED EQH/3QAEAAf/xAE/AAABBQEBAQEBAQAAAAAAAAADAAECBAUGBwgJCgsBAAEFAQEBAQEBAAAAAAAA AAEAAgMEBQYHCAkKCxAAAQQBAwIEAgUHBggFAwwzAQACEQMEIRIxBUFRYRMicYEyBhSRobFCIyQV UsFiMzRygtFDByWSU/Dh8WNzNRaisoMmRJNUZEXCo3Q2F9JV4mXys4TD03Xj80YnlKSFtJXE1OT0 pbXF1eX1VmZ2hpamtsbW5vY3R1dnd4eXp7fH1+f3EQACAgECBAQDBAUGBwcGBTUBAAIRAyExEgRB UWFxIhMFMoGRFKGxQiPBUtHwMyRi4XKCkkNTFWNzNPElBhaisoMHJjXC0kSTVKMXZEVVNnRl4vKz hMPTdePzRpSkhbSVxNTk9KW1xdXl9VZmdoaWprbG1ub2JzdHV2d3h5ent8f/2gAMAwEAAhEDEQA/ APVJAIBOp4C5ofXOq3rw6ZTTNDbPSsvcdd3HsZ+7uWF9durdTwPrLjX1OLasdjX4/wC66f56f3t3 0Fk3WMr69Rn4v9Gz7WX1/wAklw9ao/yqrPaqmXmCDwx04ZDi8Yu/yPweEsQy5an7+GUsVaDHl/dl /X4P/Uj6R+1g3LdS9o9IP2B4Os+bVoSJidR2Xn1fVmP6rk2XOjHxbH3XnyafZWP5VtnsU/qp1vqP UvrTbfJNF1bje381rW/zP9Xb9FHHzB4uGWvFKo+TBm+DzGOeQVAYcQyTvaUukP7/AA/9w9+kqfV+ qUdI6ZkdSyA51OKz1HhmriP5KqZ/1mwcH6vD6wWssdiurZaGNA3xZG32z/KVpx3XSWVhfWLCzerW 9Jqa8X049eS5zh7dloBYB/K9yfp/1gw8/qXUem1Ne23pbmtvc4ANO8bhsPySU6iS53pX146P1azq FWE2x9nTmueWkAG1jS5pfj6+9u5qd/136Oz6sD6zHf8AYyQ30wB6m8u9L0ts7dzXJKehSWDk/XHp VHQMbr0WWY2Y5jKK2AGwvsO0V7Z+k3a5Bzfrz0/HzrOn4uLldRyscD7SzFr3isn8yx8tbvSU9Iku cy/rrj4tOC6zp+Z9o6iLTThisesPRG9+6vd+4NySSn//0GzsL6w9JyLemZmLZ1Lpm8uoJBeNpMtf Rc2X0W/vq90PoZzHCineK2WNyGMvaWWUvaRua7822m5ns31/nrr/AKw/VjF661hsuuxbqtG20uI0 PLHs+i5WOj9Cwej0+njBz3uH6S6xxc939Zx/76q/3f13+i7I+MEctwjTMf3R6OL/ADkv/QXjOu9C OI99Vm/0r7XZFgoaX2Wkk+nUxv8Ag6qG/n2f4RUsDA671G1nTsLFs6f08vBuMFsgfn5Fztrrn/us XoXVejYPVqfSymuDm/QtrJa9v9V7VW6D9W8bovqPZfbk3WaGy50w391jPotTTy3r00h4HX+6yY/j QHLVL1Z4/KJx4sfF/nB6vmj/AF/8Br/Ximx31N6nTU11j/s+1rWglxgt/NauN659Vc6v6hNyW9Q6 jkWGik/s97t1YJ2zX6AZv21r1JJWnCfP68x31e+tbuqdRxr/ALBndOx6q8iqt1obZW1m+u1tQc9n 0VmOzOrNr+sXU+n4mRW/6xZFWL0zfW5ryCHMtyHsjdVW1n5716mkkp8ts6R9aPqvk9I6tfRj2YnT gMK9mEHusfRYfe+9jh79rzv9qjV0jOH1mr+q32Z7+inqH7VbaWn0/SNZt+znTb/OL1RJJT5b0bpf UrPrNjfVrIx3jpnRc2/PZc4HY9p9+JU130PY96AMDI6J1zqzOqZHVsJmXkG/HyOnNL6rWuLnfpNj Xu9Rm5espJKfMuturf8A828tmR1N2JW3M9TPDHHMbLHsbu9m5u5/6P8A4tJempJKf//Z/9sAQwAI BgYHBgUIBwcHCQkICgwUDQwLCwwZEhMPFB0aHx4dGhwcICQuJyAiLCMcHCg3KSwwMTQ0NB8nOT04 MjwuMzQy/9sAQwEJCQkMCwwYDQ0YMiEcITIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIy MjIyMjIyMjIyMjIyMjIyMjIy/8AAEQgAIABmAwEiAAIRAQMRAf/EAB8AAAEFAQEBAQEBAAAAAAAA AAABAgMEBQYHCAkKC//EALUQAAIBAwMCBAMFBQQEAAABfQECAwAEEQUSITFBBhNRYQcicRQygZGh CCNCscEVUtHwJDNicoIJChYXGBkaJSYnKCkqNDU2Nzg5OkNERUZHSElKU1RVVldYWVpjZGVmZ2hp anN0dXZ3eHl6g4SFhoeIiYqSk5SVlpeYmZqio6Slpqeoqaqys7S1tre4ubrCw8TFxsfIycrS09TV 1tfY2drh4uPk5ebn6Onq8fLz9PX29/j5+v/EAB8BAAMBAQEBAQEBAQEAAAAAAAABAgMEBQYHCAkK C//EALURAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBRCkaGxwQkjM1LwFWJy 0QoWJDThJfEXGBkaJicoKSo1Njc4OTpDREVGR0hJSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoKD hIWGh4iJipKTlJWWl5iZmqKjpKWmp6ipqrKztLW2t7i5usLDxMXGx8jJytLT1NXW19jZ2uLj5OXm 5+jp6vLz9PX29/j5+v/aAAwDAQACEQMRAD8A99LKCASAT0FcOvxDin8XjRre2Bt1l8mS4Zud3Tge ma5X4j67qukeObG5hdkhto1e3H8L5+9n1z0rnriVIvF9pqdmP9E1CdLiPn7pLDcp9wcj8q8+vimn yx0sz6zLsihOj7WtrzxbXk/87a/f2PazrqpqL27oBEsnlhwec+4rYyCSM8jtXj0OupJ4hvZbhytr aSvNOfYHhfqTgVJ4G8R6nrfxAuLklzbTRMZlz8qKPu/THSnSxT5rS1u9Dlr5HNU5VVooxu/8vX/g dz1+iszX9at/Dug3mr3Su9vax+Y4jGWI9qz9U8ZafpXgtfFE0U7WTQpKEVRvw2McZ967z506Oiuf 03xbY6n4juNDhjmFzBaR3bMw+Xa4BA+vIp2leKrHV9d1nSIElSfSXVJ2cAKdwyMH8KAN6iuM0P4l 6J4hn1eDTkuJJdNRpCpUAzICQWTnkZFK/wASdEj8Ar4wInNiSF8sKPMD7tu3GcZBoA7KiuSu/iDo 9p4NsvE22eW0vWRII41BkZ2OAuM9Rg/lVbUviXptnq82lWem6pql7bgfaUsbfzBCT2Y5xn2oA7ai uB134q6V4b0nTb7VdM1K3N/v2W7xASJtOPmGeOtFAHnupab4l8P3s+kX+nT6ro/mFoCVLgAngo45 RvUfpWr4a8NnUmFrB5qwxyrcol0hSS3YEZB7MrDjI74r0TxX4MtPFSRNLd3VpcRcLNbyEHHcEdDV zQPDGn+G7XyrNZHdv9ZPM5d3+p/oK4/q153ex9Is9ccNyrSfktL93/wN+uh5n4m8NNp8ssEvm+Rc TtcyC2QvJOSTtUDsqjue5NZumaX4h1meLStP06fTNLLgzHaV3Ad3c8sfbp7V7Frnh6w8QWohvEcM v3JYmKun0P8AjVHwx4PtfDJleO7urueQYMk75wvoB0FTLC+/psa0s/UcLaWtRbXWl++/57dNCp8S reR/hjrlvBG8shtNqqilmbkdhXmniXwPqEPweS7XW/EFzKbWE/2dI+6MHjK7MZwP6V73RXcfLHj8 V+3g34ivrOq2F9/ZmoaPbwx3MFu0oWRAMqwUZB4rDe/1hIPGWsaXpl/HJ4lu4rPTPMhZXIwQ0hGM qAO59a98ooA8Fl0Dxb4DvvDmuXNnp8tlpiiwnTTUdpJIHPJcEc4Jzx3pkOgagvj2HwV9gmfw+dY/ thZmQ+X5XllvLPGOuePWvfaKAPBfD2iapL48svB91ZTLpGhalPqKTsp2SKeY1B6cE5/Oqg0u58Le LfEMes33imwjvLs3FvcaOheKdSSfmwCcjOK+haKAPm34sWlxqvhPwrJpi6zqcY8/M13CxnPzD74x ke3tRX0lRQB//9k= --f403045dd1804e92d905428eff0f-- From nobody Wed Nov 30 18:50:35 2016 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 B9747129693 for ; Wed, 30 Nov 2016 18:50:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 6sxMRwMaP5f6 for ; Wed, 30 Nov 2016 18:50:26 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86B111294B2 for ; Wed, 30 Nov 2016 18:50:26 -0800 (PST) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5B651284F7D; Thu, 1 Dec 2016 02:50:25 +0000 (UTC) Date: Thu, 1 Dec 2016 02:50:25 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20161201025025.GP26244@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: [TLS] Draft 18 certificate signature algorithm requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: tls@ietf.org 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: Thu, 01 Dec 2016 02:50:29 -0000 We've discussed this before, and the current state of the text is certainly much improved. I'd like to touch on one final point. The current text reads: Section 4.4.1.2 ( https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 ) All certificates provided by the server MUST be signed by a signature algorithm that appears in the "signature_algorithms" extension provided by the client, if they are able to provide such a chain (see Section 4.2.3). Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. If the server cannot produce a certificate chain that is signed only via the indicated supported algorithms, then it SHOULD continue the handshake by sending the client a certificate chain of its choice that may include algorithms that are not known to be supported by the client. This fallback chain MAY use the deprecated SHA-1 hash algorithm only if the "signature_algorithms" extension provided by the client permits it. If the client cannot construct an acceptable chain using the provided certificates and decides to abort the handshake, then it MUST abort the handshake with an "unsupported_certificate" alert. The first and second paragraph are in conflict, unless the first paragraph's MUST is changed to a SHOULD, or a "MUST if at all possible", ... That is it fine to require the server to send a compatible rather than an incompatible certificate when it has at least one of each, but if the only choice is to fail, the second paragraph says that the server "SHOULD" send what it has, thus the first is not really a MUST as written. The only compromise in the direction of the first paragraph made in the second is that certificates (not self) signed with SHA1 MUST not be sent if the client did not offer to support it, even if that's the only certificate it has, and even if that SHA1 signature will never be used by the client (e.g. with a DANE-EE(3) TLSA record authenticating the server directly). The onus is correctly placed on the client (not on the server) to abort the connection, if the client's security requirements are not met by the server's certificate chain. So I'd like to see the text in the first paragraph changed to a SHOULD or worst-case a qualified "MUST whenever possible". I should also note that the second part of the first paragraph, which says: Certificates that are self-signed or certificates that are expected to be trust anchors are not validated as part of the chain and therefore MAY be signed with any algorithm. assumes that the server knows which of its certificates are trust anchors, but this is not something that the server can in general definitely know. All kinds of clients may use all kinds of methods to validate the server chain. So I think there is a final opportunity to polish the text by making it clear that the server SHOULD (whenever possible) send a certificate chain that the client is likely to be able to process, but otherwise proceed to the text in the second paragraph, which says (correctly) that it SHOULD otherwise send what it has, which may indeed prove sufficient to the client despite the apparent signature algorithm mismatch. On a related note, is there in the current draft anything that requires ECDSA certificates to bear ECDSA issuer signatures? Or has that finally been relaxed, allowing the transmission of EE ECDSA certs bearing RSA signatures (ideally the client also signals support for RSA signatures)? This would lift the restriction imposed by: https://tools.ietf.org/search/rfc4492#section-2.2 In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- capable public key and be signed with ECDSA. My impression is that the text in the last paragraph of 4.4.1.4: https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.4.1.4 Note that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with an ECDSA key). seems to have the desired effect. Is that correct? If so, should the change from 4492 be stated more emphatically, making it clear that the older restriction no longer applies? -- Viktor. From nobody Wed Nov 30 19:51:46 2016 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 B4B9112943B for ; Wed, 30 Nov 2016 19:51:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 YjWtPVuveqBn for ; Wed, 30 Nov 2016 19:51:42 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (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 296A4126579 for ; Wed, 30 Nov 2016 19:51:42 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id t125so174948272ywc.1 for ; Wed, 30 Nov 2016 19:51:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=WOS/+SfOmmLodf1U4d45K0uyxqkuVHvx7eBPCr27EMM=; b=uRT69CvXBWEjd2r16bynF713aj5oCLOkfWeP7gpSX0r9vR22yLvg2nnmfbsshWiNQJ TVpCBP2elWK+VRAOM9wBMikQPWpNis1vvMfOVyedNIMrfsJ7ALuVrSAdbrnEswpg053C PtwsIxCBkC8g9HEsO88C0jgg6JciegbMXqXs9gp+XsY70VPk+gKCA8d2/Z5VP0/K0DNe AqWo1rLQGyrMXYczO9u5MxMJJTj8MKKQE4As+7mj8mbFeJsAEOHFnIVnfYexmmRF48f0 e7pZozvCYOE8Fbe6At/hyN7HK5yNzFc/N1S0GJW51etQXyO+CboLRwqprUGFVJUX+L0r dq6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=WOS/+SfOmmLodf1U4d45K0uyxqkuVHvx7eBPCr27EMM=; b=i8D1BZxhWpKqy2oVELNYxoYUF1Hc61TtfDcMQi4EZUv/db7zyvDubIlxu5CI18pDbN h3iF5w4Ie9jxTyOw3+yd0W6SiLQBQgP/k8+EyG4jcXcLImRubp9kiMKUb+dNfw/8tjR7 +Rxj7TpDnLJSDkUfUvnvGRonuFrCmLt1ksWlehXWSWN9Nof0262uZCQDp9JG5Oxx0zv2 nxCo2O08O3aeIIbTzRTJWqipvW1tOHoWfUwoB1WXvB3EhA/hjDMOXeBdl8By+/lu8InC oRpnnpTQbfU5P9mX+Zp12G/gBWMyxboWGVdZaHYCNyMDGqxhseuKpTjBB0Mf33Ckxtwu Hm2g== X-Gm-Message-State: AKaTC00KDL7J/NoZkex55SyNfbzPT9Jk7s4TxGRJgZaKKAlDIbZEHvOPVm4ihDfMPf0ilQaFxbOIQ+7tJp0Kvw== X-Received: by 10.129.108.216 with SMTP id h207mr39572680ywc.52.1480564301177; Wed, 30 Nov 2016 19:51:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.164.210 with HTTP; Wed, 30 Nov 2016 19:51:00 -0800 (PST) In-Reply-To: <20161201025025.GP26244@mournblade.imrryr.org> References: <20161201025025.GP26244@mournblade.imrryr.org> From: Eric Rescorla Date: Wed, 30 Nov 2016 22:51:00 -0500 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a114dd36e3d6daf054290bd8c Archived-At: Subject: Re: [TLS] Draft 18 certificate signature algorithm requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 01 Dec 2016 03:51:44 -0000 --001a114dd36e3d6daf054290bd8c Content-Type: text/plain; charset=UTF-8 On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni wrote: > > We've discussed this before, and the current state of the text is > certainly much improved. I'd like to touch on one final point. > > The current text reads: > > Section 4.4.1.2 ( https://tools.ietf.org/html/ > draft-ietf-tls-tls13-18#page-56 ) > > All certificates provided by the server MUST be signed by a signature > algorithm that appears in the "signature_algorithms" extension > provided by the client, if they are able to provide such a chain (see > Section 4.2.3). Certificates that are self-signed or certificates > that are expected to be trust anchors are not validated as part of > the chain and therefore MAY be signed with any algorithm. > > If the server cannot produce a certificate chain that is signed only > via the indicated supported algorithms, then it SHOULD continue the > handshake by sending the client a certificate chain of its choice > that may include algorithms that are not known to be supported by the > client. This fallback chain MAY use the deprecated SHA-1 hash > algorithm only if the "signature_algorithms" extension provided by > the client permits it. If the client cannot construct an acceptable > chain using the provided certificates and decides to abort the > handshake, then it MUST abort the handshake with an > "unsupported_certificate" alert. > > The first and second paragraph are in conflict, unless the first > paragraph's MUST is changed to a SHOULD, or a "MUST if at all > possible", ... That is it fine to require the server to send a > compatible rather than an incompatible certificate when it has at > least one of each, but if the only choice is to fail, the second > paragraph says that the server "SHOULD" send what it has, thus > the first is not really a MUST as written. > It's "MUST if... ". That's different from SHOULD unless because it means that the unless clause is that only reason for violating it, and then if that condition obtains it SHOULD do X but could presumably do other things. The onus is correctly placed on the client (not on the server) to > abort the connection, if the client's security requirements are not > met by the server's certificate chain. > > So I'd like to see the text in the first paragraph changed to a > SHOULD or worst-case a qualified "MUST whenever possible". > I don't see any difference between "MUST whenever possible" and the current language. On a related note, is there in the current draft anything that > requires ECDSA certificates to bear ECDSA issuer signatures? No. Nor has that been true since TLS 1.2. See: https://tools.ietf.org/search/rfc5246#section-7.4.2 If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same. Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical. > Or > has that finally been relaxed, allowing the transmission of EE > ECDSA certs bearing RSA signatures (ideally the client also signals > support for RSA signatures)? This would lift the restriction > imposed by: > > https://tools.ietf.org/search/rfc4492#section-2.2 > > In ECDHE_ECDSA, the server's certificate MUST contain an ECDSA- > capable public key and be signed with ECDSA. > > My impression is that the text in the last paragraph of 4.4.1.4: > > https://tools.ietf.org/html/draft-ietf-tls-tls13-18#section-4.4.1.4 > > Note that a certificate containing a key for one signature algorithm > MAY be signed using a different signature algorithm (for instance, an > RSA key signed with an ECDSA key). > > seems to have the desired effect. Is that correct? If so, should > the change from 4492 be stated more emphatically, making it clear > that the older restriction no longer applies? > Given that ECDHE_ECDSA is not even a concept in TLS 1.3, I don't see that this text is relevant. -Ekr > > -- > Viktor. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a114dd36e3d6daf054290bd8c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni <= ietf-dane@dukho= vni.org> wrote:

We've discussed this before, and the current state of the text is
certainly much improved.=C2=A0 I'd like to touch on one final point.
The current text reads:

=C2=A0 =C2=A0Section 4.4.1.2 ( https://to= ols.ietf.org/html/draft-ietf-tls-tls13-18#page-56 )

=C2=A0 =C2=A0All certificates provided by the server MUST be signed by a si= gnature
=C2=A0 =C2=A0algorithm that appears in the "signature_algorithms"= extension
=C2=A0 =C2=A0provided by the client, if they are able to provide such a cha= in (see
=C2=A0 =C2=A0Section 4.2.3).=C2=A0 Certificates that are self-signed or cer= tificates
=C2=A0 =C2=A0that are expected to be trust anchors are not validated as par= t of
=C2=A0 =C2=A0the chain and therefore MAY be signed with any algorithm.

=C2=A0 =C2=A0If the server cannot produce a certificate chain that is signe= d only
=C2=A0 =C2=A0via the indicated supported algorithms, then it SHOULD continu= e the
=C2=A0 =C2=A0handshake by sending the client a certificate chain of its cho= ice
=C2=A0 =C2=A0that may include algorithms that are not known to be supported= by the
=C2=A0 =C2=A0client.=C2=A0 This fallback chain MAY use the deprecated SHA-1= hash
=C2=A0 =C2=A0algorithm only if the "signature_algorithms" extensi= on provided by
=C2=A0 =C2=A0the client permits it.=C2=A0 If the client cannot construct an= acceptable
=C2=A0 =C2=A0chain using the provided certificates and decides to abort the=
=C2=A0 =C2=A0handshake, then it MUST abort the handshake with an
=C2=A0 =C2=A0"unsupported_certificate" alert.

The first and second paragraph are in conflict, unless the first
paragraph's MUST is changed to a SHOULD, or a "MUST if at all
possible", ...=C2=A0 That is it fine to require the server to send a compatible rather than an incompatible certificate when it has at
least one of each, but if the only choice is to fail, the second
paragraph says that the server "SHOULD" send what it has, thus the first is not really a MUST as written.

<= div>It's "MUST if... ". That's different from SHOULD unle= ss because it
means that the unless clause is that only reason fo= r violating it, and then
if that condition obtains it SHOULD do X= but could presumably do
other things.

<= br>
The onus is correctly placed on the client (not on the server) to
abort the connection, if the client's security requirements are not
met by the server's certificate chain.

So I'd like to see the text in the first paragraph changed to a
SHOULD or worst-case a qualified "MUST whenever possible".

I don't see any difference between "= MUST whenever possible"
and the current language.
<= div>

On a related note, is there in the current draft anything that
requires ECDSA certificates to bear ECDSA issuer signatures?

No. Nor has that been true since TLS 1.2. See:

<= pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar= gin-bottom:0px;color:rgb(0,0,0)"> If the client provided a "signatur= e_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature algorithm (for instance, an RSA key signed with a DSA key). This is a departure from TLS 1.1, which required that the algorithms be the same. Note that this also implies that the DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA key exchange algorithms do not restrict the algorithm used to sign the certificate. Fixed DH certificates MAY be signed with any hash/signature algorithm pair appearing in the extension. The names DH_DSS, DH_RSA, ECDH_ECDSA, and ECDH_RSA are historical.


=C2=A0
Or
has that finally been relaxed, allowing the transmission of EE
ECDSA certs bearing RSA signatures (ideally the client also signals
support for RSA signatures)?=C2=A0 This would lift the restriction
imposed by:

=C2=A0 =C2=A0https://tools.ietf.org/search/rfc= 4492#section-2.2

=C2=A0 =C2=A0In ECDHE_ECDSA, the server's certificate MUST contain an E= CDSA-
=C2=A0 =C2=A0capable public key and be signed with ECDSA.

My impression is that the text in the last paragraph of 4.4.1.4:

=C2=A0 =C2=A0https://tools.ietf.o= rg/html/draft-ietf-tls-tls13-18#section-4.4.1.4

=C2=A0 =C2=A0Note that a certificate containing a key for one signature alg= orithm
=C2=A0 =C2=A0MAY be signed using a different signature algorithm (for insta= nce, an
=C2=A0 =C2=A0RSA key signed with an ECDSA key).

seems to have the desired effect.=C2=A0 Is that correct?=C2=A0 If so, shoul= d
the change from 4492 be stated more emphatically, making it clear
that the older restriction no longer applies?

Given that ECDHE_ECDSA is not even a concept in TLS 1.3, I don't= see
that this text is relevant.


-Ekr
=C2=A0

--
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Viktor.

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--001a114dd36e3d6daf054290bd8c-- From nobody Wed Nov 30 20:28:31 2016 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 A494E129558 for ; Wed, 30 Nov 2016 20:28:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 L9cnt-ec8d1M for ; Wed, 30 Nov 2016 20:28:28 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA85F129444 for ; Wed, 30 Nov 2016 20:28:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1480566508; x=1512102508; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=31pRVC27vptUS2zfLPx4+LHMW+2GgVQ6KOdIW8z/kio=; b=hGW5bM8yCFvDsZYPFoxnPdBp2LXclRvhPLsSr3HJk0VUwhPABYUwUaQF LOeF+4Np0VnnQHsOBgZLK+xJZoIfGXF+ohj3I+CPD7erFkPXPJuWCapbg MMQMFwPwQ9GIo/X26d+fo4tHAw1BnNT/5vkFOyD9Pw//7aSiSim24zAEM 3CTnkhXZyqMzCz9AnBuYO42m4WtiLElN4BLM7kfOD0fL8AU/BJYt+1L2k LXda2HVV0PPpKgdtG1IX4tMTh1vLzxBKkFmtFxeAGGCfFuSQNS/7kzj+e pLNSHk5m5bwU+fCHvWciTHDzTTUlaglWeca4m6azHMR7FLB9Y2k9MJlPc g==; X-IronPort-AV: E=Sophos;i="5.31,723,1473076800"; d="scan'208";a="118222746" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.3 - Outgoing - Outgoing Received: from uxcn13-tdc-b.uoa.auckland.ac.nz ([10.6.3.3]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 Dec 2016 17:28:25 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-b.UoA.auckland.ac.nz (10.6.3.23) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Dec 2016 17:28:25 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 1 Dec 2016 17:28:25 +1300 From: Peter Gutmann To: Nick Sullivan , "" Thread-Topic: [TLS] Confirming consensus: TLS1.3->TLS* Thread-Index: AQHSQUFfD667DaatoU6RNleDGo1T66DwCVTAgAGDyICAAQa6CA== Date: Thu, 1 Dec 2016 04:28:24 +0000 Message-ID: <1480566504487.58214@cs.auckland.ac.nz> References: , In-Reply-To: Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 01 Dec 2016 04:28:30 -0000 Nick Sullivan writes:=0A= =0A= >I took a very unofficial Twitter poll on this subject:=0A= >https://twitter.com/grittygrease/status/803644086666215424=0A= =0A= Given the lack of context for the question (an out-of-the-blue query=0A= to a random bunch of people on Twitter), I think the inevitable TLSy =0A= McTLSface (given as Crypty McCryptFace in one response) is kind of =0A= representative of the quality of responses...=0A= =0A= I actually completely agree with Timothy Jackson's recent posting:=0A= =0A= =A0 After 15 years, everyone but us still calls it SSL. We need to =0A= =A0 admit that we lost the marketing battle and plan for a world where =0A= =A0 everyone calls =93TLS X=94 =93SSL X=94. Even =93new=94 implementations = call =0A= =A0 themselves =93LibreSSL=94 and =93BoringSSL=94 rather than =93LibreTLS= =94 or =0A= =A0 =93BoringTLS=94.=0A= =0A= Spurred by that, I've been watching out for any uses of $protocol-=0A= name that I come across in news, books, journals, blogs, whatever.=0A= It's pretty clear cut: What we call TLS, the rest of the world calls=0A= SSL.=A0 The only place where it was referred to specifically as TLS=0A= was in IETF WG postings and in conference papers.=A0 To the rest of=0A= the world, the protocol is SSL.=A0 So given that the world will know =0A= it as SSL , it had better have a number that makes =0A= explicit what precedence it takes, either 4 or 2017.=A0 Whatever it=0A= is, it needs to be something that can be ranked against "SSL" and=0A= "SSL 3" and be an obvious improvement.=0A= =0A= Peter.= From nobody Wed Nov 30 20:32:15 2016 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 12A96129512 for ; Wed, 30 Nov 2016 20:32:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 1VWnxI889K75 for ; Wed, 30 Nov 2016 20:32:12 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 133461293DA for ; Wed, 30 Nov 2016 20:32:12 -0800 (PST) Received: from [10.42.2.143] (unknown [107.14.54.1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 2C814284EAC for ; Thu, 1 Dec 2016 04:32:11 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: Date: Wed, 30 Nov 2016 23:32:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20161201025025.GP26244@mournblade.imrryr.org> To: "tls@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Draft 18 certificate signature algorithm requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "tls@ietf.org" 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: Thu, 01 Dec 2016 04:32:14 -0000 > On Nov 30, 2016, at 10:51 PM, Eric Rescorla wrote: >=20 >=20 >=20 > On Wed, Nov 30, 2016 at 9:50 PM, Viktor Dukhovni = wrote: >=20 > The current text reads: >=20 > Section 4.4.1.2 ( = https://tools.ietf.org/html/draft-ietf-tls-tls13-18#page-56 ) >=20 > All certificates provided by the server MUST be signed by a = signature > algorithm that appears in the "signature_algorithms" extension > provided by the client, if they are able to provide such a chain = (see > Section 4.2.3). Certificates that are self-signed or certificates > that are expected to be trust anchors are not validated as part of > the chain and therefore MAY be signed with any algorithm. >=20 > [...] >=20 > It's "MUST if... ". That's different from SHOULD unless because it > means that the unless clause is that only reason for violating it, and = then > if that condition obtains it SHOULD do X but could presumably do > other things. Yes, I see. The stretch of text between the "MUST" and the "if" just = happened to overflow my stack limit when I was rereading this today... Please = pardon the short attention span. So all is well, unless there is merit it = trying to word-smith the text to bring the "MUST" and "if" closer together.... The good new is that the intent is already just right. > I don't see any difference between "MUST whenever possible" > and the current language. Yes, fair enough... > On a related note, is there in the current draft anything that > requires ECDSA certificates to bear ECDSA issuer signatures? >=20 > No. Nor has that been true since TLS 1.2. See: > https://tools.ietf.org/search/rfc5246#section-7.4.2 Great. Thanks. --=20 Viktor. From nobody Wed Nov 30 20:36:41 2016 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 9BCC1129512 for ; Wed, 30 Nov 2016 20:36:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.096 X-Spam-Level: X-Spam-Status: No, score=-7.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-2.896] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=auckland.ac.nz 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 BPbZg7beZQdH for ; Wed, 30 Nov 2016 20:36:38 -0800 (PST) Received: from mx4.auckland.ac.nz (mx4.auckland.ac.nz [130.216.125.248]) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0388127076 for ; Wed, 30 Nov 2016 20:36:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=mail; t=1480566997; x=1512102997; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=LPj5+uwDtfazW/3eeHo5nqwWpA7ORlGuVuTnjeXEZaw=; b=HIzOprPgzHjKhHoWTpBccVsy7pSr0SP0YdgqAyxi1ySXC0gYcU06X5NB HzvsFTa3Pq7Odt+w2Jb3/Ytv6beWrrlMGnwTtan8cWL0Yxitv5yWKA4Sc Yt9O5qYZYRuUeAfRoFolNWK/9nKHImoOLBmXTFZMDYAv6g4zmLuNSnTn3 x8UGXxfSyBHJJN2m+QE4RUsS83cuhlJRTK9Sb1QaWtloFlnqy8lBbvAnY QcIjv6Fk3xB4uilm4iMNe8vnVBLXUVpsNdI3E7XJNawIwk8XPthiN6Ud5 p3S6919eBr7H7Kr0Q6FqiGxX72Wow0L99D9TS30B/FTYXPBQVTZUbayOa A==; X-IronPort-AV: E=Sophos;i="5.31,723,1473076800"; d="scan'208";a="118223619" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 10.6.3.2 - Outgoing - Outgoing Received: from uxcn13-tdc-a.uoa.auckland.ac.nz ([10.6.3.2]) by mx4-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 Dec 2016 17:36:19 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz (10.6.2.5) by uxcn13-tdc-a.UoA.auckland.ac.nz (10.6.3.22) with Microsoft SMTP Server (TLS) id 15.0.1178.4; Thu, 1 Dec 2016 17:36:18 +1300 Received: from uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) by uxcn13-ogg-d.UoA.auckland.ac.nz ([10.6.2.25]) with mapi id 15.00.1178.000; Thu, 1 Dec 2016 17:36:18 +1300 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Draft 18 certificate signature algorithm requirements Thread-Index: AQHSS322fKOg2d22jE+sJCpuIo6pBqDygZHH Date: Thu, 1 Dec 2016 04:36:17 +0000 Message-ID: <1480566976732.22966@cs.auckland.ac.nz> References: <20161201025025.GP26244@mournblade.imrryr.org> In-Reply-To: <20161201025025.GP26244@mournblade.imrryr.org> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [TLS] Draft 18 certificate signature algorithm requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 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: Thu, 01 Dec 2016 04:36:39 -0000 Viktor Dukhovni writes:=0A= =0A= >So I'd like to see the text in the first paragraph changed to a SHOULD or = =0A= >worst-case a qualified "MUST whenever possible".=0A= =0A= Why is that whole thing even there in the first place? From the previous = =0A= discussions where this came up, the pretty much universal consensus was tha= t =0A= people were ignoring the requirement because it served no obvious purpose = =0A= but broke interoperability. Unless you're a server operator that chooses t= o =0A= buy a whole bunch of $995 certs, one per algorithm, from a CA that allows = =0A= you to choose which algorithm gets used for signing, the whole thing is =0A= completely inapplicable. You send whatever cert chain the CA gave you to = =0A= the client, and it's up to them to decide whether they want to accept or = =0A= reject. What would be lost by simply removing that entire block of text, = =0A= since it's being ignored by implementers anyway? The solution is to remove= =0A= it, not to fiddle with it until it becomes a no-op that matches what =0A= everyone is doing anyway.=0A= =0A= (This seems to be getting like PKIX where a mistake is never actually =0A= corrected, just watered down again and again over successive iterations of = a =0A= spec until it's finally quietly dropped when no-one is looking).=0A= =0A= Peter.=0A= From nobody Wed Nov 30 20:43:32 2016 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 AC255128B37 for ; Wed, 30 Nov 2016 20:43:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 0U2SwkYWqeDG for ; Wed, 30 Nov 2016 20:43:29 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D543127076 for ; Wed, 30 Nov 2016 20:43:28 -0800 (PST) Received: from [10.42.2.143] (unknown [107.14.54.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 1CEE0284B67 for ; Thu, 1 Dec 2016 04:43:28 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <1480566504487.58214@cs.auckland.ac.nz> Date: Wed, 30 Nov 2016 23:43:38 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1480566504487.58214@cs.auckland.ac.nz> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Confirming consensus: TLS1.3->TLS* X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "" 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: Thu, 01 Dec 2016 04:43:30 -0000 > On Nov 30, 2016, at 11:28 PM, Peter Gutmann = wrote: >=20 > I actually completely agree with Timothy Jackson's recent posting: >=20 > After 15 years, everyone but us still calls it SSL. We need to=20 > admit that we lost the marketing battle and plan for a world where=20= > everyone calls =93TLS X=94 =93SSL X=94. Even =93new=94 = implementations call=20 > themselves =93LibreSSL=94 and =93BoringSSL=94 rather than =93LibreTLS=94= or=20 > =93BoringTLS=94. I'll drink to that! I also find it amusing that muttered under one's breath, with just a touch of voicing on the "s" sounds, SSL sounds rather like "azazel", which seems rather apt: https://en.wikipedia.org/wiki/Azazel --=20 Viktor. From nobody Wed Nov 30 20:49:16 2016 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 C2C59129420 for ; Wed, 30 Nov 2016 20:49:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no 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 IMBZxtGvT3cY for ; Wed, 30 Nov 2016 20:49:12 -0800 (PST) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F7A9128B37 for ; Wed, 30 Nov 2016 20:49:12 -0800 (PST) Received: from [10.42.2.143] (unknown [107.14.54.2]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 4CFF0284B67 for ; Thu, 1 Dec 2016 04:49:10 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Viktor Dukhovni In-Reply-To: <1480566976732.22966@cs.auckland.ac.nz> Date: Wed, 30 Nov 2016 23:49:26 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <003A6783-D318-436E-833E-9E6E75778132@dukhovni.org> References: <20161201025025.GP26244@mournblade.imrryr.org> <1480566976732.22966@cs.auckland.ac.nz> To: "" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [TLS] Draft 18 certificate signature algorithm requirements X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: "" 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: Thu, 01 Dec 2016 04:49:14 -0000 > On Nov 30, 2016, at 11:36 PM, Peter Gutmann = wrote: >=20 > Why is that whole thing even there in the first place? =46rom the = previous=20 > discussions where this came up, the pretty much universal consensus = was that=20 > people were ignoring the requirement because it served no obvious = purpose=20 > but broke interoperability. Unless you're a server operator that = chooses to=20 > buy a whole bunch of $995 certs, one per algorithm, from a CA that = allows=20 > you to choose which algorithm gets used for signing, the whole thing = is=20 > completely inapplicable. You send whatever cert chain the CA gave you = to=20 > the client, and it's up to them to decide whether they want to accept = or=20 > reject. What would be lost by simply removing that entire block of = text,=20 > since it's being ignored by implementers anyway? The solution is to = remove > it, not to fiddle with it until it becomes a no-op that matches what=20= > everyone is doing anyway. I would agree, if indeed everyone were ignoring this. Sadly, that's not the case. In particular try to send to use a CAcert-issued client cert to send email with STARTTLS to outlook.com... So I wanted to see explicit text saying that the server SHOULD send what it has. Some folks here probably still think you and I (and perhaps = ekr) are wrong, and that the server should drop the connection... This is = not an invitation to reopen that wound. --=20 Viktor.