From nobody Thu Jun 1 00:11:02 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 757B71292AE for ; Thu, 1 Jun 2017 00:11:00 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 RXMFYLkYinNV for ; Thu, 1 Jun 2017 00:10:58 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 2C784128B90 for ; Thu, 1 Jun 2017 00:10:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 4FD7361F28; Thu, 1 Jun 2017 10:10:56 +0300 (EEST) 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 8lWb7PSCEQmb; Thu, 1 Jun 2017 10:10:56 +0300 (EEST) 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 ED25221C; Thu, 1 Jun 2017 10:10:55 +0300 (EEST) Date: Thu, 1 Jun 2017 10:10:53 +0300 From: Ilari Liusvaara To: Victor Vasiliev Cc: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= , "tls@ietf.org" Message-ID: <20170601071053.GA8573@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Jun 2017 07:11:00 -0000 On Wed, May 31, 2017 at 03:49:03PM -0400, Victor Vasiliev wrote: > On Tue, May 30, 2017 at 9:56 PM, Colm MacCárthaigh > wrote: > > > Here you argue, essentially, that it is too inconvenient to mitigate those > > attacks for users. I don't think we can seriously take that approach. > > > > If the methods are too inconvenient, the secure alternative is to not use > > 0-RTT at all. > > > > [snip] > > > > I think I am not getting my key point across here clearly. I am not arguing > that they are inconvenient, I am arguing that the guarantee you are trying > to provide is impossible. TLS level "sent data is delivered at most once" is very much possible. But it requires synchronous state. And it seems like where "few replays @TLS" would be easier than "no replays @TLS", is where the replays would be to different servers, with each server only accepting once. But "few replays" distributed among different servers is much more dangerous than "few replays" to one server. Yes, residual replays will still come through even when TLS guarantees "at most once" behavior. But turns out one already has to handle that form of replay, due to wonders of web browser behavior (and reordering attacks abusing timeouts). It is TLS not guaranteeing "at most once" behavior (especially across servers) that enables new attacks. This is fundamentially about what is REQUIRED to do 0-RTT without nasty security holes. If you think this is too difficult, just don't do 0-RTT. One extra RTT is a lot better than nasty attacks, with potential consequences much worse than just some site getting DoSed or some card chargebacks. -Ilari From nobody Thu Jun 1 10:00:26 2017 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 023A41296CD; Thu, 1 Jun 2017 10:00:19 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.52.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149633641896.22124.5821905813477826968@ietfa.amsl.com> Date: Thu, 01 Jun 2017 10:00:19 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-dnssec-chain-extension-04.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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 Jun 2017 17:00:19 -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 : A DANE Record and DNSSEC Authentication Chain Extension for TLS Authors : Melinda Shore Richard Barnes Shumon Huque Willem Toorop Filename : draft-ietf-tls-dnssec-chain-extension-04.txt Pages : 23 Date : 2017-06-01 Abstract: This draft describes a new TLS extension for transport of a DNS record set serialized with the DNSSEC signatures needed to authenticate that record set. The intent of this proposal is to allow TLS clients to perform DANE authentication of a TLS server without needing to perform additional DNS record lookups. It will typically not be used for general DNSSEC validation of TLS endpoint names. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-dnssec-chain-extension/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-dnssec-chain-extension-04 https://datatracker.ietf.org/doc/html/draft-ietf-tls-dnssec-chain-extension-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-dnssec-chain-extension-04 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 Thu Jun 1 13:51:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A96FF127444 for ; Thu, 1 Jun 2017 13:51:06 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 GMa0pSGNqCJ3 for ; Thu, 1 Jun 2017 13:51:03 -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 98B1B1200C5 for ; Thu, 1 Jun 2017 13:50:56 -0700 (PDT) Received: by mail-qt0-x232.google.com with SMTP id f55so46025217qta.3 for ; Thu, 01 Jun 2017 13:50:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6xy0aaqU7AXa5gLjzhGUmU9Lli9caNCv1aK5r2y4SJY=; b=fE9aycc82qVWBlu0Sd9orTKdXEz+c1kkMo19QBnXI+/VC6E0Gr+vipoZWLY6J1qWmY j85KS2nSVxfDdZ0+8zhr6puOalTF2h9me7TqU99BzkdaqZvAlzIPacmwuDaAzb0GI1sS 6LfALozkUwl9KFQOiq1e75xAHdOycu1XAmPpF055x70uhHBiGANM5POxBqglrcX8Il6z K5SC1JyuOaY/njF09mRuY7xq40zDOgYNPi2KwLMo4THg0Z3NCwW9gb9EeXzB0uSCpZNE zp2w9nfABUODlpnPBNaylQXbZxN9gnoDGBH0DYmw810ZLJOdQYa65kEotRDnH8Tmlrs/ q4rw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6xy0aaqU7AXa5gLjzhGUmU9Lli9caNCv1aK5r2y4SJY=; b=JHR5pdfqtcRRuQ4KipE/+5WDSs/vbPwap43Ip9dwDr6w4Z9TmUkYZsVGq9qKLy2dlQ QmKHnz8SS4Hj5Ms9ByC41EGI70SGfHtRcr/wNgsP5Y7i6V36ijA5nBaKNZVANMU6PM9T QMhUuZIQaYTFHe69TzmqktZe0tf0w0rxDNsqpGyRuCq6wwPhNgGmU/NLmIo7f+hWnuMT D0S7sGpie1czKw8LAie2MwHGr+qWv29UUHhFj5ib1NWlboW2zT7pt1By2R1UaY9PHGlr qVksCqomq2jftfbj4rFDkwKO3YDMVqpA5mpRxYzBsX7GERFKtb9nAJ7/GTto7szRuop3 r/lw== X-Gm-Message-State: AODbwcBfEYLAjDXpjtueYluBuqvZcs4QER5LnQYbR0WQaGq8+EvG7VxA fux4WByJu77e5/RUwmZp2gp+BmxFhS47VFZ0YA== X-Received: by 10.237.61.39 with SMTP id g36mr4322644qtf.60.1496350255532; Thu, 01 Jun 2017 13:50:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.65 with HTTP; Thu, 1 Jun 2017 13:50:54 -0700 (PDT) In-Reply-To: References: From: Victor Vasiliev Date: Thu, 1 Jun 2017 16:50:54 -0400 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11432b707120730550ec3130" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Jun 2017 20:51:07 -0000 --001a11432b707120730550ec3130 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 31, 2017 at 4:52 PM, Colm MacC=C3=A1rthaigh wrote: > > On Wed, May 31, 2017 at 12:49 PM, Victor Vasiliev > wrote: > >> I think I am not getting my key point across here clearly. I am not >> arguing >> that they are inconvenient, I am arguing that the guarantee you are >> trying to >> provide is impossible. >> >> I wholeheartedly agree that if it is possible to provide guarantee B (ze= ro >> replays), we really should provide it. The problem is, we cannot. Sinc= e >> 0-RTT >> is by its very design declinable, there will be always a possibility for >> at >> least one retry. >> > > This is the part we agree on; but as I've said before, the kinds of > attacks enabled by these kinds of client-initiated retries, and by > attacker-initiated replays are fundamentally different. > I am not sure I agree with this distinction. I can accept the difference i= n terms of how much attacker can retry -- but we've already agreed that bounding that number is a good idea. I don't see any meaningful distinction in othe= r regards. > > >> Once you concede you can have at least one replay, the difference betwee= n >> one >> replay and N replays (for all N > 0) is not that large, which is why I >> refer to >> this as "nebulous bound" (guarantee C). >> > > There's a very big difference and it leads to real-world attacks. With > many replays, all sorts of side-channel analyses become possible, and I'v= e > provided examples. It's particularly nasty that the replays can be > out-of-bound and to arbitrary nodes of the attacker's choosing, which mak= es > the attacks even more effective. > Sure, but this is just an argument for making N small. Also, retrys can also be directed to arbitrary nodes. > >> Your applications already have to >> contend with replays, it's now just the matter of preventing side-channe= l >> amplification. >> > > Yes; applications using 0-RTT do have to make themselves retry-tolerant, > as they already must in many scenarios (e.g. a browser driven applicatio= n). > I am glad we agree on that point. > What concerns me most here is that people are clearly being confused by > the TLS 1.3 draft into mis-understanding how this interacts with 0-RTT. F= or > example the X-header trick, to derive an idempotency token from the binde= r, > that one experimental deployment innovated doesn't actually work because = it > doesn't protect against the DKG attack. We're walking into rakes here. > Of course it doesn't protect against the DKG attack, but nothing at that layer actually does. This sounds like an issue with the current wording of the draft. As I mentioned, I believe we should be very clear on what the developers should and should not expect from TLS. > So, in other words, since we're now just bargaining about the value of N, >> operational concerns are a fair game. >> > > They're still not fair game imo, because there's a big difference between > permitting exactly > one duplicate, associated with a client-driven retry, and permitting huge > volumes of replays. They enable different kinds of attacks. > > Sure, but there's a space between "one" and "huge amount". > I keep forgetting about forward secrecy in all of this, but it's worth > noting that your argument for globally resumable sessions also implies th= at > we shouldn't really shoot for FS for some of the most critical user data= . > I also find that bizarre. > > To clarify, I am not suggesting that two streams would help. I completel= y >> agree with you that two streams is not going to mitigate the DKG attack = or >> others. What I meant is that 0-RTT inherently has slightly different >> properties from 1-RTT and must be used with that in mind. Specifically,= I >> meant that it will not be enabled for applications by default, and HTTP >> clients >> would only allow it for methods that RFC 7231 defines as safe. >> > > Well in the real world, I think it'll be pervasive, and I even think it > /should/ be. We should make 0-RTT that safe and remove the sharp edges. > Are you arguing that non-safe requests should be allowed to be sent via 0-RTT? Because that actually violates reasonable expectations of security guarantees for TLS, and I do not believe that is acceptable. >> I do not believe that this to be the case. The DKG attack is an attack >> that allows >> for a replay. >> > > It's not. It permits a retry. The difference here is that the client is i= n > full control. It can decide to delay, to change a unique request ID, or > even not to retry at all. But the legitimate client generated the first > attempt, it can be signaled that it wasn't accepted, and then it generate= s > the second attempt. If it really really needs to it can even reason about > the complicated semantics of the earlier request being possibly > re-submitted later by an attacker. > That's already not acceptable for a lot of applications -- and by enabling 0-RTT for non-safe HTTP requests, we would be pulling the rug from under them. Replays are different though; the attacker just literally copies the data > and can resend and resend as desired. As I've shown; this breaks real-wor= ld > things like authenticated throttling systems, and leads to side-channel a= nd > cache analysis; where only very rarely is one attempt sufficient to > exploit. > Sure, but all of those are either: (a) side channel attacks covered by guarantee C, or (b) a violation of semantic contract between TLS and the application. > [snip] > > >> But, as you describe, this enables some interesting side channels. Now, >> these >> side channels exist even without 0-RTT. Attackers already can measure >> response >> times, probe and groom caches, direct traffic, etc. *But*, with unlimit= ed >> 0-RTT replay, the attacker can repeat the experiment unboundedly and >> amplify >> the side channel. >> > > Exactly :) but also ... what about the attack on the throttling > infrastructure? or other resource exhaustion? 0-RTT replay seems like a > really big problem here and it seems like the most realistic kind of atta= ck > too; booters and trouble-makers trying to lock each other out of systems. > Throttling POST requests is fine -- they shouldn't go over 0-RTT, since the= y are not idempotent. Throttling GET requests in this manner goes at odds with RFC 7231: Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server. This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. [...] Incidentally, guarantee C does solve the throttling problem -- if you get N replays, you get promise of 1/(N+1) throttled resource available to you. Deployments which do this with GETs may want to deploy the measures to make N very small. Also, since they already keep track of the state for throttlin= g purposes, they might add a strike register on top of that. > > Thus, A is problematic. I think we both believe this and both agree then >> that >> the current text is unsatisfactory. So the question is what to replace = it >> with. Whatever we provide, it should be a clear security guarantee >> between the >> application and TLS (depending on what guarantee we chose, some of your >> other >> attacks may or may not just be invalid uses of TLS). B is obviously >> preferable, but as it is impossible per DKG, I think we should set the >> contract >> at C (bounded replay protection). This is a guarantee that is not >> fundamentally impossible and also successfully mitigates your side chann= el >> amplification attacks. >> > > I'm all for bounded replay protection, with the bounds being 1 ;-) > Why not 2? What is the difference between 1 and 2? 2 and 3? 3 and 24? None of the proposed attacks distinguishes 1 replay and N replays in qualitative ways (as opposed to giant semantic leap between 0 and 1 replay); only in ho= w much damage you can do, or how much information you can extract from the side channel. -- Victor. --001a11432b707120730550ec3130 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On W= ed, May 31, 2017 at 4:52 PM, Colm MacC=C3=A1rthaigh <<= a href=3D"mailto:colm@allcosts.net" target=3D"_blank">colm@allcosts.net= > wrote:
On We= d, May 31, 2017 at 12:49 PM, Victor Vasiliev <vasilvv@google.com>= wrote:
= I think I am not getting my key point across here clearly.=C2=A0 I am not a= rguing
that they are inconvenient, I am argu= ing that the guarantee you are trying to
provide is impossible.

I wholeheartedly agree that if it is possible= to provide guarantee B (zero
replays), we really should provide = it.=C2=A0 The problem is, we cannot.=C2=A0 Since 0-RTT
is by its = very design declinable, there will be always a possibility for at
least one retry.

=
This is the part we agree on; but as I've said before, the = kinds of attacks enabled by these kinds of client-initiated retries, and by= attacker-initiated replays are fundamentally different.=C2=A0
<= /div>

I am not sure I agree with this= distinction.=C2=A0 I can accept the difference in
terms of how m= uch attacker can retry -- but we've already agreed that bounding
<= div>that number is a good idea.=C2=A0 I don't see any meaningful distin= ction in other
regards.=C2=A0
=C2=A0
Once you concede you can have at least one replay, = the difference between one
replay and N replays (for all N > 0= ) is not that large, which is why I refer to
this as "nebulo= us bound" (guarantee C).=C2=A0

There's a very big difference and it lead= s to real-world attacks. With many replays, all sorts of side-channel analy= ses become possible, and I've provided examples. It's particularly = nasty that the replays can be out-of-bound and to arbitrary nodes of the at= tacker's choosing, which makes the attacks even more effective.=C2=A0

Sure, but this is ju= st an argument for making N small.=C2=A0 Also, retrys can also
be= directed to arbitrary nodes.=C2=A0

=C2=A0
Your applications already have to
=
contend with replays, it's now just the matter of preventing side-= channel
amplification.
=

Yes; applications using 0-RTT do have to make th= emselves retry-tolerant, =C2=A0as they already must in many scenarios (e.g.= a browser driven application).
I am glad we agree on that point.
=C2=A0
What concerns me most here is = that people are clearly being confused by the TLS 1.3 draft into mis-unders= tanding how this interacts with 0-RTT. For example the X-header trick, to d= erive an idempotency token from the binder, that one experimental deploymen= t innovated doesn't actually work because it doesn't protect agains= t the DKG attack. We're walking into rakes here.=C2=A0

Of course it doesn't protect ag= ainst the DKG attack, but nothing at that layer
actually does.

This sounds like an issue with the current wording o= f the draft.=C2=A0 As I
mentioned, I believe we should be very cl= ear on what the developers should and
should not expect from TLS.= =C2=A0


<= div>So, in other words, since we're now just bargaining about the value= of N,
operational concerns are a fair game.

They're still not fair= game imo, because there's a big difference between permitting exactly<= br>
one duplicate, associated with a client-driven retry, and per= mitting huge volumes of replays. They enable different kinds of attacks.=C2= =A0


= Sure, but there's a space between "one" and "huge amount= ".
=C2=A0
I keep forgetting about forward secrecy in all of this, bu= t it's worth noting that your argument for globally resumable sessions = also implies that we shouldn't really shoot for =C2=A0FS for some of th= e most critical user data. I also find that bizarre. =C2=A0

To clari= fy, I am not suggesting that two streams would help.=C2=A0 I completely
agree with you that two streams is not going to mitigate the DKG att= ack or
others.=C2=A0 What I meant is that 0-RTT inherently has sl= ightly different
properties from 1-RTT and must be used with that= in mind.=C2=A0 Specifically, I
meant that it will not be enabled= for applications by default, and HTTP clients
would only allow i= t for methods that RFC 7231 defines as safe.
<= /blockquote>

Well in the real world, I think it&#= 39;ll be pervasive, and I even think it /should/ be. We should make 0-RTT t= hat safe and remove the sharp edges.=C2=A0

Are you arguing that non-safe requests should be al= lowed to be sent via 0-RTT?
Because that actually violates reason= able expectations of security guarantees
for TLS, and I do not be= lieve that is acceptable.


I do not believe that this to be the ca= se.=C2=A0 The DKG attack is an attack that allows
for a replay.= =C2=A0

It's not. It permits a retry. The difference here is that the client i= s in full control. It can decide to delay, to change a unique request ID, o= r even not to retry at all. But the legitimate client generated the first a= ttempt, it can be signaled that it wasn't accepted, and then it generat= es the second attempt. If it really really needs to it can even reason abou= t the complicated semantics of the earlier request being possibly re-submit= ted later by an attacker.=C2=A0
That's already not acceptable for a lot of applicatio= ns -- and by enabling
0-RTT for non-safe HTTP requests, we would = be pulling the rug from under them.

Replays are different though; the att= acker just literally copies the data and can resend and resend as desired. = As I've shown; this breaks real-world things like authenticated throttl= ing systems, and leads to side-channel and cache analysis; where only very = rarely is one attempt sufficient to exploit.=C2=A0

Sure, but all of those are either:
=C2=A0(a) side channel attacks covered by guarantee C, or
= =C2=A0(b) a violation of semantic contract between TLS and the application.=
=C2=A0
=
[snip]
=C2=A0
But, as you describe, this enables some in= teresting side channels. Now, these
side channels exist even with= out 0-RTT.=C2=A0 Attackers already can measure response
times, pr= obe and groom caches, direct traffic, etc. =C2=A0*But*, with unlimited
0-RTT replay, the attacker can repeat the experiment unboundedly and = amplify
the side channel.

Exactly :) but also ... what about the = attack on the throttling infrastructure? or other resource exhaustion? 0-RT= T replay seems like a really big problem here and it seems like the most re= alistic kind of attack too; booters and trouble-makers trying to lock each = other out of systems.=C2=A0

Throttling POST requests is fine -- they shouldn't go ove= r 0-RTT, since they
are not idempotent.=C2=A0 Throttling GET requ= ests in this manner goes at odds with
RFC 7231:
<= br>
=C2=A0 =C2=A0Request methods are considered "safe" = if their defined semantics are
=C2=A0 =C2=A0essentially read-only= ; i.e., the client does not request, and does
=C2=A0 =C2=A0not ex= pect, any state change on the origin server as a result of
=C2=A0= =C2=A0applying a safe method to a target resource.=C2=A0 Likewise, reasona= ble
=C2=A0 =C2=A0use of a safe method is not expected to cause an= y harm, loss of
=C2=A0 =C2=A0property, or unusual burden on the o= rigin server.

=C2=A0 =C2=A0This definition of safe= methods does not prevent an implementation
=C2=A0 =C2=A0from inc= luding behavior that is potentially harmful, that is not
=C2=A0 = =C2=A0entirely read-only, or that causes side effects while invoking a safe=
=C2=A0 =C2=A0method.=C2=A0 What is important, however, is that t= he client did not
=C2=A0 =C2=A0request that additional behavior a= nd cannot be held accountable for
=C2=A0 =C2=A0it. [...]

Incidentally, guarantee C does solve the throttling proble= m -- if you get N
replays, you get promise of 1/(N+1) throttled r= esource available to you.
Deployments which do this with GETs may= want to deploy the measures to make N
very small.=C2=A0 Also, si= nce they already keep track of the state for throttling
purposes,= they might add a strike register on top of that.

Thus, A is problematic.=C2= =A0 I think we both believe this and both agree then that
the cur= rent text is unsatisfactory.=C2=A0 So the question is what to replace it
with.=C2=A0 Whatever we provide, it should be a clear security guar= antee between the
application and TLS (depending on what guarante= e we chose, some of your other
attacks may or may not just be inv= alid uses of TLS).=C2=A0 B is obviously
preferable, but as it is = impossible per DKG, I think we should set the contract
at C (boun= ded replay protection).=C2=A0 This is a guarantee that is not
fun= damentally impossible and also successfully mitigates your side channel
amplification attacks.

I'm all for bounded replay protection, wi= th the bounds being 1 ;-)=C2=A0
Why not 2?=C2=A0 What is the difference between 1 and 2? = =C2=A02 and 3? =C2=A03 and 24?=C2=A0 None
of the proposed attacks= distinguishes 1 replay and N replays in qualitative
ways (as opp= osed to giant semantic leap between 0 and 1 replay); only in how
= much damage you can do, or how much information you can extract from the si= de
channel.

=C2=A0 -- Victor.
--001a11432b707120730550ec3130-- From nobody Thu Jun 1 14:14:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71CF128B8F; Thu, 1 Jun 2017 14:14:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.92 X-Spam-Level: X-Spam-Status: No, score=-6.92 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_PASS=-0.001, URIBL_BLOCKED=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 9ayPBxYm3IH8; Thu, 1 Jun 2017 14:14:38 -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 0364E127873; Thu, 1 Jun 2017 14:14:38 -0700 (PDT) Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (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 3wf0Tm0Lbsz1JXQ; Thu, 1 Jun 2017 23:14:36 +0200 (CEST) X-purgate-ID: 152705::1496351676-0000521C-C1A4C5B2/0/0 X-purgate-size: 3129 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 mail08.wdf.sap.corp (Postfix) with ESMTP id 3wf0Tl5NP9z2xR2; Thu, 1 Jun 2017 23:14:35 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id B3AFA1A6B5; Thu, 1 Jun 2017 23:14:35 +0200 (CEST) In-Reply-To: To: Watson Ladd Date: Thu, 1 Jun 2017 23:14:35 +0200 (CEST) CC: "mrex@sap.com" , Eric Rescorla , tls-chairs , The IESG , draft-ietf-tls-ecdhe-psk-aead@ietf.org, "tls@ietf.org" Reply-To: mrex@sap.com 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: <20170601211435.B3AFA1A6B5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] Eric Rescorla's Discuss on draft-ietf-tls-ecdhe-psk-aead-04: (with DISCUSS and COMMENT) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Jun 2017 21:14:41 -0000 Watson Ladd wrote: >Martin Rex wrote: >> >> The suggestion to accept a recognized TLSv1.2 cipher suite code point >> as an alternative indicator for the highest client-supported protocol >> version is not really a "mechanism". It's efficient (with 0-bytes on >> the wire), intuitive and extremely backwards-compatible (will not upset >> old servers, neither version-intolerant as the Win2008/2012 servers, >> nor extension-intolerant servers. > > It's a substantial change made after WG last call. That alone makes it > improper. If you want to get WG consensus for such a change, go ahead. > But don't try making this in the dead of night. The proposed small addition of when the TLS cipher suites can be negotiated is clearly *NOT* a change, and certainly not substantial. Implementors that want to completely ignore this small addition can do so and will remain fully compliant, they will not have to change a single line of code. For those implementing the proposed addition there will be two very desirable effects: 1) make more TLS handshakes succeed 2) make more TLS handshakes use TLS protocol version TLSv1.2 rather than TLSv1.1 or TLSv1.0 come at an extremely low cost, and this addition has ZERO downsides. The IETF is about promoting interoperability. You seem to have a problem with either or both of the above outcomes, but I fail to understand which and why. > >> It's worse -- there are still TLS servers out there which choke on >> TLS extensions (and TLS server which choke on extension ordering). > > TLS 1.2 demands extensions work. Sending a TLS 1.2 hello without > extensions is going to make it impossible to implement many features > TLS 1.2 security relies on. Actually, it does not. TLSv1.2 works just fine without TLS extension, although there are a few implementations in the installed base which got this wrong. rfc5246 appendix E.2 shows that TLSv1.2 interop with extension-less ClientHellos was desired and assumed to be possible. Some implementors got it wrong. > >> It seems that there are others facing the same issue: >> >> https://support.microsoft.com/en-us/help/3140245/update-to-enable-tls-1.1-and-tls-1.2-as-a-default-secure-protocols-in-winhttp-in-windows >> >> and defer enabling to explicit customer opt-in. >> >> >> Really, a very compatible and extremely robust and useful approach would >> be to allow implied client protocol version indication through presence of >> TLSv1.2-only cipher suite codepoints and this would allow large parts >> of the installed base to quickly start using TLSv1.2--without breaking >> existing usage scenarios and without the hazzle for users having to opt-in >> and test stuff. > > The people who have these problems are not "large parts" of the > install base. They are large parts of *your* install base. Don't > confuse these two. The above WinHTTP issue alone applies to Win7, which is about 50% of the installed base of Desktops PCs. Refering to ~50% of the installed base as "large parts" seems OK to me. YMMV. -Martin From nobody Thu Jun 1 16:59:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340E112420B for ; Thu, 1 Jun 2017 16:59:15 -0700 (PDT) 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=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 bNz9uFKvWYfT for ; Thu, 1 Jun 2017 16:59:12 -0700 (PDT) Received: from mail-yb0-x233.google.com (mail-yb0-x233.google.com [IPv6:2607:f8b0:4002: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 A38E1126CD8 for ; Thu, 1 Jun 2017 16:59:12 -0700 (PDT) Received: by mail-yb0-x233.google.com with SMTP id 202so14496015ybd.0 for ; Thu, 01 Jun 2017 16:59:12 -0700 (PDT) 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=v2surQplLIWoJDcDy4tXoIsDD4yIIqXbkFmwABL4Y34=; b=0zUgfroN5htQnrgDujOT24I2Pg7vhpn/ux+DyGaEL7/fle2riiku1c1mEXEd1MTMX1 E9BaiNVBU0jfhk0hwBY/pEPmjguUYL9Cgkxrq84EcvTTjTAEWqhrFdtkZUy+YS2oDLlX kRdu76PLPfeRXKtrQD/kfS/BwWR0Uiz2aMuK66RM2FclAQHYiGBQjDpdvtAHs/47S15i T6H/+iNcg5c/Ug2Scvm10po2dMIyCg8kDuoLAWp95s95aWXfi8mAohEg81OzlAxaHMBl g8SuzJBKDSTRk6HIIXUTdfVgBxlIdZ/6qBPuNxqvtzrYAINqpTqpQWZAYC3OQF7Wj0L6 Cyrg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=v2surQplLIWoJDcDy4tXoIsDD4yIIqXbkFmwABL4Y34=; b=QBW2d7sPDKmp8YZ0Yn60cl+FxtndXFq8rb6ZwoyB7lKp1gan6TImy4chfbojOJvdjI jCQoePQj1raJy9wTXYgaDnuecUiwTab9a7hRzzJu9DGBgkUb6E6p88ul4ab6Sf0f3QF3 0uaua4KhtSMmBuGjksDZkZ9iuuhYeyjLKmGfGOFJR0QYy+A9lg0e3Dd/fdnkzupzLRrw XkbT7dLVdPgJbbE2D3rMXLq3TRdAgjeUS/35SWCQ9tlzKjftufxk79nHjx2WIiJlnoJH qOq4cAmn8OqZuNGLuBqik7XHdrT36C0YtCQ0JcoVDEcitO2ERnchA2SWBHOLRxVeJtHI wlKA== X-Gm-Message-State: AODbwcAP8Ihs8xPi0JBta5S9wwbYxbnssRzBdxNNxdfVa0DGCUB4GJ87 iyKMELE5ossA/CvJbrO8iV6a2I4Wxgxd X-Received: by 10.37.170.98 with SMTP id s89mr20370537ybi.19.1496361551746; Thu, 01 Jun 2017 16:59:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.93.70 with HTTP; Thu, 1 Jun 2017 16:59:10 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Thu, 1 Jun 2017 16:59:10 -0700 Message-ID: To: Victor Vasiliev Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19ad5cbf86b40550eed2fb" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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 Jun 2017 23:59:15 -0000 --94eb2c19ad5cbf86b40550eed2fb Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 1:50 PM, Victor Vasiliev wrote: > I am not sure I agree with this distinction. I can accept the difference > in > terms of how much attacker can retry -- but we've already agreed that > bounding > that number is a good idea. I don't see any meaningful distinction in > other > regards. > It's not just a difference in the number of duplicates. With retries, the client maintains some control, so it can do things like impose delays and update request IDs. Bill followed up with an exactly relevant example from Token Binding where the retry intentionally has a different token value. That kind of control is lost with attacker driven replays. But even if we focus on just the number; there is something special about allowing 0 literal replays of a 0-RTT section; it is easy for users to confirm/audit/test. If there's a hard-guaranteee that 0-RTT "MUST" never be replayable, then I feel like we have a hope of producing a viable 0-RTT ecosystem. Plenty of providers may screw this up, or try to cut corners, but if we can ensure that they get failing grades in security testing tools, or maybe even browser warnings, then we can corral things into a zone of safety. Otherwise, with no such mechanism, I fear that bad operators will cause the entire 0-RTT feature to be tainted and entirely turned off over time by clients. > > Sure, but this is just an argument for making N small. Also, retrys can > also > be directed to arbitrary nodes. > This is absolutely true, but see my point about the client control. Regardless, it is a much more difficult attack to carry out. That is to intercept and rewrite a whole TCP connection Vs grabbing a 0-RTT section and sending it again. > > >> What concerns me most here is that people are clearly being confused by >> the TLS 1.3 draft into mis-understanding how this interacts with 0-RTT. For >> example the X-header trick, to derive an idempotency token from the binder, >> that one experimental deployment innovated doesn't actually work because it >> doesn't protect against the DKG attack. We're walking into rakes here. >> > > Of course it doesn't protect against the DKG attack, but nothing at that > layer > actually does. > > This sounds like an issue with the current wording of the draft. As I > mentioned, I believe we should be very clear on what the developers should > and > should not expect from TLS. > Big +1 :) > So, in other words, since we're now just bargaining about the value of N, >>> operational concerns are a fair game. >>> >> >> They're still not fair game imo, because there's a big difference between >> permitting exactly >> one duplicate, associated with a client-driven retry, and permitting huge >> volumes of replays. They enable different kinds of attacks. >> >> > Sure, but there's a space between "one" and "huge amount". > It's not just quantitive, it's qualitative too. But now I'm duplicating myself more than once ;-) > Well in the real world, I think it'll be pervasive, and I even think it >> /should/ be. We should make 0-RTT that safe and remove the sharp edges. >> > > Are you arguing that non-safe requests should be allowed to be sent via > 0-RTT? > Because that actually violates reasonable expectations of security > guarantees > for TLS, and I do not believe that is acceptable. > I'm just saying that it absolutely will happen, and I don't think any kind of lawyering about the HTTP spec and REST will change that. Folks use GETs for non-idempotent side-effect-bearing APIs a lot. And those folks don't generally understand TLS or have anything to do with it. I see no real chance of that changing and it's a bit of a deceit for us to think that it's realistic that there will be these super careful 0-RTT deployments where everyone from the Webserver administrator to the high-level application designer is coordinating and fully aware of all of the implications. It crosses layers that are traditionally quite far apart. So with that in mind, I argue that we have to make TLS transport as secure as possible by default, while still delivering 0-RTT because that's such a beneficial improvement. > I do not believe that this to be the case. The DKG attack is an attack >>> that allows >>> for a replay. >>> >> >> It's not. It permits a retry. The difference here is that the client is >> in full control. It can decide to delay, to change a unique request ID, or >> even not to retry at all. But the legitimate client generated the first >> attempt, it can be signaled that it wasn't accepted, and then it generates >> the second attempt. If it really really needs to it can even reason about >> the complicated semantics of the earlier request being possibly >> re-submitted later by an attacker. >> > > That's already not acceptable for a lot of applications -- and by enabling > 0-RTT for non-safe HTTP requests, we would be pulling the rug from under > them. > Yep; but I think /this/ risk is manageable and tolerable. Careful clients, like the token binding case, can actually mitigate this. I've outlined the scheme. For careless clients, like browsers, they can mostly ignore this; since they retry so easily anyway, it's no worse. But there is *no* proposed mitigation for replayable 0-RTT. So I don't think that's manageable. Just trying to make a data-driven decision. If someone presents an alternative mitigation (besides forbidding replays), I'll change my mind. > Throttling POST requests is fine -- they shouldn't go over 0-RTT, since > they > are not idempotent. Throttling GET requests in this manner goes at odds > with > RFC 7231. > Throttling GET requests happens all of the time and is an important security and fairness measure used by many deployed systems. 0-RTT would break it. That's not ok. I don't think it is at odds with RFC 7231 ... which also defines the 503 status code. Incidentally, guarantee C does solve the throttling problem -- if you get N > replays, you get promise of 1/(N+1) throttled resource available to you. > Deployments which do this with GETs may want to deploy the measures to > make N > very small. Also, since they already keep track of the state for > throttling > purposes, they might add a strike register on top of that. > One could implement a strike register like that, in the same way as a coordinated throttling system, they have some things in common. Though it crosses layers. I'm all for bounded replay protection, with the bounds being 1 ;-) >> > > Why not 2? What is the difference between 1 and 2? 2 and 3? 3 and 24? > None > of the proposed attacks distinguishes 1 replay and N replays in qualitative > ways (as opposed to giant semantic leap between 0 and 1 replay); only in > how > much damage you can do, or how much information you can extract from the > side > channel. > You keep discarding my points about client control and focusing just on the number; but there quantitative and qualitative differences. That kind of argument isn't very productive and doesn't move us forward. But I've answered above too. -- Colm --94eb2c19ad5cbf86b40550eed2fb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 1, 2017 at 1:50 PM, Victor Vasiliev <<= a href=3D"mailto:vasilvv@google.com" target=3D"_blank">vasilvv@google.com> wrote:
I am not sure I agr= ee with this distinction.=C2=A0 I can accept the difference in
te= rms of how much attacker can retry -- but we've already agreed that bou= nding
that number is a good idea.=C2=A0 I don't see any meani= ngful distinction in other
regards.=C2=A0

It's not just a difference in the = number of duplicates. With retries, the client maintains some control, so i= t can do things like impose delays and update request IDs. Bill followed up= with an exactly relevant example from Token Binding where the retry intent= ionally has a different token value. That kind of control is lost with atta= cker driven replays.=C2=A0

But even if we focus on= just the number; there is something special about allowing 0 literal repla= ys of a 0-RTT section; it is easy for users to confirm/audit/test. If there= 's a hard-guaranteee that 0-RTT "MUST" never be replayable, t= hen I feel like we have a hope of producing a viable 0-RTT ecosystem. Plent= y of providers may screw this up, or try to cut corners, but if we can ensu= re that they get failing grades in security testing tools, or maybe even br= owser warnings, then we can corral things into a zone of safety. Otherwise,= with no such mechanism, I fear that bad operators will cause the entire 0-= RTT feature to be tainted and entirely turned off over time by clients.=C2= =A0

=
Sure, but this is just an argument for making N small.=C2=A0 Also, ret= rys can also
be directed to arbitrary nodes.=C2=A0

This is absolutely true, but = see my point about the client control. Regardless, it is a much more diffic= ult attack to carry out. That is to intercept and rewrite a whole TCP conne= ction Vs grabbing a 0-RTT section and sending it again.=C2=A0
=C2= =A0
=C2=A0
What concerns me most here is= that people are clearly being confused by the TLS 1.3 draft into mis-under= standing how this interacts with 0-RTT. For example the X-header trick, to = derive an idempotency token from the binder, that one experimental deployme= nt innovated doesn't actually work because it doesn't protect again= st the DKG attack. We're walking into rakes here.=C2=A0

Of course it doesn't pr= otect against the DKG attack, but nothing at that layer
actually = does.

This sounds like an issue with the current w= ording of the draft.=C2=A0 As I
mentioned, I believe we should be= very clear on what the developers should and
should not expect f= rom TLS.=C2=A0

= Big +1 :)=C2=A0
=C2=A0
<= div class=3D"gmail_extra">
So, in other words, since we're= now just bargaining about the value of N,
operational concerns a= re a fair game.

They're still not fair game imo, because there's a big di= fference between permitting exactly
one duplicate, associated= with a client-driven retry, and permitting huge volumes of replays. They e= nable different kinds of attacks.=C2=A0


Sure, but there's a space be= tween "one" and "huge amount".
<= /blockquote>

It's not just quantitive, it's qual= itative too. But now I'm duplicating myself more than once ;-)=C2=A0
=C2=A0
Well in the real world, I think it&= #39;ll be pervasive, and I even think it /should/ be. We should make 0-RTT = that safe and remove the sharp edges.=C2=A0

Are you arguing that non-safe requests shou= ld be allowed to be sent via 0-RTT?
Because that actually violate= s reasonable expectations of security guarantees
for TLS, and I d= o not believe that is acceptable.
<= div>
I'm just saying that it absolutely will happen, and = I don't think any kind of lawyering about the HTTP spec and REST will c= hange that. Folks use GETs for non-idempotent side-effect-bearing APIs a lo= t. And those folks don't generally understand TLS or have anything to d= o with it. I see no real chance of that changing and it's a bit of a de= ceit for us to think that it's realistic that there will be these super= careful 0-RTT deployments where everyone from the Webserver administrator = to the high-level application designer is coordinating and fully aware of a= ll of the implications. It crosses layers that are traditionally quite far = apart.=C2=A0

So with that in mind, I argue that we= have to make TLS transport as secure as possible by default, while still d= elivering 0-RTT because that's such a beneficial improvement.=C2=A0
=C2=A0
I do not believe that this to be the case.=C2=A0 The D= KG attack is an attack that allows
for a replay.=C2=A0

It's not. It= permits a retry. The difference here is that the client is in full control= . It can decide to delay, to change a unique request ID, or even not to ret= ry at all. But the legitimate client generated the first attempt, it can be= signaled that it wasn't accepted, and then it generates the second att= empt. If it really really needs to it can even reason about the complicated= semantics of the earlier request being possibly re-submitted later by an a= ttacker.=C2=A0

That's already not acceptable for a lot of applications -- and = by enabling
0-RTT for non-safe HTTP requests, we would be pulling= the rug from under them.
Yep; but I think /this/ risk is manageable and tolerable. Care= ful clients, like the token binding case, can actually mitigate this. I'= ;ve outlined the scheme. For careless clients, like browsers, they can most= ly ignore this; since they retry so easily anyway, it's no worse.=C2=A0=

But there is *no* proposed mitigation for replaya= ble 0-RTT. So I don't think that's manageable. Just trying to make = a data-driven decision. If someone presents an alternative mitigation (besi= des forbidding replays), I'll change my mind.=C2=A0
=C2=A0
Throttling POST requests is fine --= they shouldn't go over 0-RTT, since they
are not idempotent.= =C2=A0 Throttling GET requests in this manner goes at odds with
R= FC 7231.

Thro= ttling GET requests happens all of the time and is an important security an= d fairness measure used by many deployed systems. 0-RTT would break it. Tha= t's not ok.=C2=A0

I don't think it is at o= dds with RFC 7231 ... which also defines the 503 status code.=C2=A0


Incidentally, g= uarantee C does solve the throttling problem -- if you get N
= replays, you get promise of 1/(N+1) throttled resource available to you.
Deployments which do this with GETs may want to deploy the measures= to make N
very small.=C2=A0 Also, since they already keep track = of the state for throttling
purposes, they might add a strike reg= ister on top of that.

One could implement a strike register like that, in the same way as = a coordinated throttling system, they have some things in common. Though it= crosses layers. =C2=A0

=
I'm all= for bounded replay protection, with the bounds being 1 ;-)=C2=A0

Why not 2?=C2=A0= What is the difference between 1 and 2? =C2=A02 and 3? =C2=A03 and 24?=C2= =A0 None
of the proposed attacks distinguishes 1 replay and N rep= lays in qualitative
ways (as opposed to giant semantic leap betwe= en 0 and 1 replay); only in how
much damage you can do, or how mu= ch information you can extract from the side
channel.
=

You keep discarding my p= oints about client control and focusing just on the number; but there quant= itative and qualitative differences. That kind of argument isn't very p= roductive and doesn't move us forward.=C2=A0 But I've answered abov= e too.=C2=A0

--
Colm
--94eb2c19ad5cbf86b40550eed2fb-- From nobody Thu Jun 1 17:22:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DCC5129AF3 for ; Thu, 1 Jun 2017 17:22:57 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 Upyv5PIibhM0 for ; Thu, 1 Jun 2017 17:22:54 -0700 (PDT) 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 4CF72129AE3 for ; Thu, 1 Jun 2017 17:22:54 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id l14so27087351ywk.1 for ; Thu, 01 Jun 2017 17:22:54 -0700 (PDT) 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=rQkhvt4EJYWfEUYq6o2KLTRjIlW5iiyrgp9Mg9B5KAM=; b=0le9+7YoGvHJ5qg1kp1OgwQOuS+5zShGWExEkMbtWCo+ebQR1itP71icNMVJy3qW1Z sirUD/Ve/6G6TphDfRU1u5qKCwflEomG/ct04a+Ph9J4oeV30hAS7poa82VJwYP/f/rz dwUcwmsnnBgAZH2Euc+3O9u8ArnQk+JkJ60XqPizf7bh7HihiFATfw76TjkoDS6p0Fyt 5h+2gIqjT4CPZAym9hKM7tE8Wu+ymsiYoWI4TbNzWmmFoZf4EqCML8B0Kmhh+NqGkoOq 7vTptvCsOjmDsOYAKHG2Er44NO0Rnil619kzGuqM0LX0CCpsGuXb5vmD0tYnqJB3b92Q zWMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rQkhvt4EJYWfEUYq6o2KLTRjIlW5iiyrgp9Mg9B5KAM=; b=Semxrn1P8K783n1CrsTcO2ttCeMxBm/k29kVqSu8eHij/S6SLNn2ilXTRu2eQJL4Ex JEr3dNJYWFGSxMfmQfeuuGPCetHWy8/Ju6ji0U/3avLNqfrDEHW/lWnCs3tXECYp50hI 7kX5oDsxgTj9gAOhGzDygcmPtgrMmt54Zug77x8F6rEoHIYDpITuBrgy9Bo+emP5g5AV jt7uVrDCfypapWJ4l70uNvA9aZzvKnB6fO4Tcrpx3tjAmdTux3jnnmUl9QKGUZObQkd4 1kGxlC4MiIyj9Wh6IfcWWtEK5gDHyjobYKnY3/6+7eXI5KfPUjMr52KCDuxd/j13tQb4 VK4A== X-Gm-Message-State: AODbwcA3k9bLlZXbW09ncz6GcfiLe0PRxq+4kkZpi6Rqpu7gWakS4SAS 2cCvZ0dgqlxNBhlR3ww6C9Gu1ZDS5gjrexk6lA== X-Received: by 10.129.104.69 with SMTP id d66mr3585836ywc.74.1496362973508; Thu, 01 Jun 2017 17:22:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.106.137 with HTTP; Thu, 1 Jun 2017 17:22:12 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 1 Jun 2017 17:22:12 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Victor Vasiliev , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11490b9a7dd4f00550ef2713" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 00:22:57 -0000 --001a11490b9a7dd4f00550ef2713 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I've just gone through this thread and I'm having a very hard time understanding what the actual substantive argument is about. Let me lay out what I think we all agree on. 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause connection failures) then a DKG-style attack where the client replays the 0-RTT data in 1-RTT is possible. 2. Because of point #1, applications must implement some form of replay-safe semantics. 3. Allowing the attacker to generate an arbitrary number of 0-RTT replays without client intervention is dangerous even if the application implements replay-safe semantics. 4. If implemented properly, both a single-use ticket and a strike-register style mechanism make it possible to limit the number of 0-RTT copies which are processed to 1 within a given zone (where a zone is defined as having consistent storage), so the number of accepted copies of the 0-RTT data is N where N is the number of zones. 5. Implementing the level of coherency to get #4 is a pain. 6. If you bind each ticket to a given zone, then you can get limit the number of accepted 0-RTT copies to 1 (for that zone) and accepted 1-RTT copies to 1 (because of the DKG attack listed above). Colm, Victor, do you disagree with this summary? -Ekr On Thu, Jun 1, 2017 at 4:59 PM, Colm MacC=C3=A1rthaigh = wrote: > > > On Thu, Jun 1, 2017 at 1:50 PM, Victor Vasiliev > wrote: > >> I am not sure I agree with this distinction. I can accept the differenc= e >> in >> terms of how much attacker can retry -- but we've already agreed that >> bounding >> that number is a good idea. I don't see any meaningful distinction in >> other >> regards. >> > > It's not just a difference in the number of duplicates. With retries, the > client maintains some control, so it can do things like impose delays and > update request IDs. Bill followed up with an exactly relevant example fro= m > Token Binding where the retry intentionally has a different token value. > That kind of control is lost with attacker driven replays. > > But even if we focus on just the number; there is something special about > allowing 0 literal replays of a 0-RTT section; it is easy for users to > confirm/audit/test. If there's a hard-guaranteee that 0-RTT "MUST" never = be > replayable, then I feel like we have a hope of producing a viable 0-RTT > ecosystem. Plenty of providers may screw this up, or try to cut corners, > but if we can ensure that they get failing grades in security testing > tools, or maybe even browser warnings, then we can corral things into a > zone of safety. Otherwise, with no such mechanism, I fear that bad > operators will cause the entire 0-RTT feature to be tainted and entirely > turned off over time by clients. > >> >> Sure, but this is just an argument for making N small. Also, retrys can >> also >> be directed to arbitrary nodes. >> > > This is absolutely true, but see my point about the client control. > Regardless, it is a much more difficult attack to carry out. That is to > intercept and rewrite a whole TCP connection Vs grabbing a 0-RTT section > and sending it again. > > >> >> >>> What concerns me most here is that people are clearly being confused by >>> the TLS 1.3 draft into mis-understanding how this interacts with 0-RTT.= For >>> example the X-header trick, to derive an idempotency token from the bin= der, >>> that one experimental deployment innovated doesn't actually work becaus= e it >>> doesn't protect against the DKG attack. We're walking into rakes here. >>> >> >> Of course it doesn't protect against the DKG attack, but nothing at that >> layer >> actually does. >> >> This sounds like an issue with the current wording of the draft. As I >> mentioned, I believe we should be very clear on what the developers >> should and >> should not expect from TLS. >> > > Big +1 :) > > >> So, in other words, since we're now just bargaining about the value of N= , >>>> operational concerns are a fair game. >>>> >>> >>> They're still not fair game imo, because there's a big difference >>> between permitting exactly >>> one duplicate, associated with a client-driven retry, and permitting >>> huge volumes of replays. They enable different kinds of attacks. >>> >>> >> Sure, but there's a space between "one" and "huge amount". >> > > It's not just quantitive, it's qualitative too. But now I'm duplicating > myself more than once ;-) > > >> Well in the real world, I think it'll be pervasive, and I even think it >>> /should/ be. We should make 0-RTT that safe and remove the sharp edges. >>> >> >> Are you arguing that non-safe requests should be allowed to be sent via >> 0-RTT? >> Because that actually violates reasonable expectations of security >> guarantees >> for TLS, and I do not believe that is acceptable. >> > > I'm just saying that it absolutely will happen, and I don't think any kin= d > of lawyering about the HTTP spec and REST will change that. Folks use GET= s > for non-idempotent side-effect-bearing APIs a lot. And those folks don't > generally understand TLS or have anything to do with it. I see no real > chance of that changing and it's a bit of a deceit for us to think that > it's realistic that there will be these super careful 0-RTT deployments > where everyone from the Webserver administrator to the high-level > application designer is coordinating and fully aware of all of the > implications. It crosses layers that are traditionally quite far apart. > > So with that in mind, I argue that we have to make TLS transport as secur= e > as possible by default, while still delivering 0-RTT because that's such = a > beneficial improvement. > > >> I do not believe that this to be the case. The DKG attack is an attack >>>> that allows >>>> for a replay. >>>> >>> >>> It's not. It permits a retry. The difference here is that the client is >>> in full control. It can decide to delay, to change a unique request ID,= or >>> even not to retry at all. But the legitimate client generated the first >>> attempt, it can be signaled that it wasn't accepted, and then it genera= tes >>> the second attempt. If it really really needs to it can even reason abo= ut >>> the complicated semantics of the earlier request being possibly >>> re-submitted later by an attacker. >>> >> >> That's already not acceptable for a lot of applications -- and by enabli= ng >> 0-RTT for non-safe HTTP requests, we would be pulling the rug from under >> them. >> > > Yep; but I think /this/ risk is manageable and tolerable. Careful clients= , > like the token binding case, can actually mitigate this. I've outlined th= e > scheme. For careless clients, like browsers, they can mostly ignore this; > since they retry so easily anyway, it's no worse. > > But there is *no* proposed mitigation for replayable 0-RTT. So I don't > think that's manageable. Just trying to make a data-driven decision. If > someone presents an alternative mitigation (besides forbidding replays), > I'll change my mind. > > >> Throttling POST requests is fine -- they shouldn't go over 0-RTT, since >> they >> are not idempotent. Throttling GET requests in this manner goes at odds >> with >> RFC 7231. >> > > Throttling GET requests happens all of the time and is an important > security and fairness measure used by many deployed systems. 0-RTT would > break it. That's not ok. > > I don't think it is at odds with RFC 7231 ... which also defines the 503 > status code. > > > Incidentally, guarantee C does solve the throttling problem -- if you get= N >> replays, you get promise of 1/(N+1) throttled resource available to you. >> Deployments which do this with GETs may want to deploy the measures to >> make N >> very small. Also, since they already keep track of the state for >> throttling >> purposes, they might add a strike register on top of that. >> > > One could implement a strike register like that, in the same way as a > coordinated throttling system, they have some things in common. Though it > crosses layers. > > I'm all for bounded replay protection, with the bounds being 1 ;-) >>> >> >> Why not 2? What is the difference between 1 and 2? 2 and 3? 3 and 24? >> None >> of the proposed attacks distinguishes 1 replay and N replays in >> qualitative >> ways (as opposed to giant semantic leap between 0 and 1 replay); only in >> how >> much damage you can do, or how much information you can extract from the >> side >> channel. >> > > You keep discarding my points about client control and focusing just on > the number; but there quantitative and qualitative differences. That kind > of argument isn't very productive and doesn't move us forward. But I've > answered above too. > > -- > Colm > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11490b9a7dd4f00550ef2713 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I've just gone through this thread and I'm ha= ving a very hard time
understanding what the actual substantive a= rgument is about.

Let me lay out what I think we a= ll agree on.

1. As long as 0-RTT is declinable (i.= e., 0-RTT does not cause
=C2=A0 =C2=A0connection failures) then a= DKG-style attack where the client
=C2=A0 =C2=A0replays the 0-RTT= data in 1-RTT is possible.

2. Because of point #1= , applications must implement some form
=C2=A0 =C2=A0of replay-sa= fe semantics.

3. Allowing the attacker to generate= an arbitrary number of 0-RTT
=C2=A0 =C2=A0replays without client= intervention is dangerous even if
=C2=A0 =C2=A0the application i= mplements replay-safe semantics.
=C2=A0 =C2=A0
4. If im= plemented properly, both a single-use ticket and a
=C2=A0 =C2=A0s= trike-register style mechanism make it possible to limit
=C2=A0 = =C2=A0the number of 0-RTT copies which are processed to 1 within
= =C2=A0 =C2=A0a given zone (where a zone is defined as having consistent
=C2=A0 =C2=A0storage), so the number of accepted copies of the 0-RTT=
=C2=A0 =C2=A0data is N where N is the number of zones.

5. Implementing the level of coherency to get #4 is a pain.=

6. If you bind each ticket to a given zone, then = you can
=C2=A0 =C2=A0get limit the number of accepted 0-RTT copie= s to 1
=C2=A0 =C2=A0(for that zone) and accepted 1-RTT copies to = 1 (because
=C2=A0 =C2=A0of the DKG attack listed above).


Colm, Victor, do you disagree with this sum= mary?

-Ekr



=C2=A0=C2=A0


On Thu, Jun 1, 2017 at 4:59 PM, Colm = MacC=C3=A1rthaigh <colm@allcosts.net> wrote:


On Thu, Jun 1, 2017 at 1:50 PM, Vic= tor Vasiliev <vasilvv@google.com> wrote:
I am not sure I agree with this distinction.=C2=A0 I can a= ccept the difference in
terms of how much attacker can retry -- b= ut we've already agreed that bounding
that number is a good i= dea.=C2=A0 I don't see any meaningful distinction in other
re= gards.=C2=A0

=
It's not just a difference in the number of duplicates. With retri= es, the client maintains some control, so it can do things like impose dela= ys and update request IDs. Bill followed up with an exactly relevant exampl= e from Token Binding where the retry intentionally has a different token va= lue. That kind of control is lost with attacker driven replays.=C2=A0
=

But even if we focus on just the number; there is somet= hing special about allowing 0 literal replays of a 0-RTT section; it is eas= y for users to confirm/audit/test. If there's a hard-guaranteee that 0-= RTT "MUST" never be replayable, then I feel like we have a hope o= f producing a viable 0-RTT ecosystem. Plenty of providers may screw this up= , or try to cut corners, but if we can ensure that they get failing grades = in security testing tools, or maybe even browser warnings, then we can corr= al things into a zone of safety. Otherwise, with no such mechanism, I fear = that bad operators will cause the entire 0-RTT feature to be tainted and en= tirely turned off over time by clients.=C2=A0

Sure, but this is just= an argument for making N small.=C2=A0 Also, retrys can also
be d= irected to arbitrary nodes.=C2=A0
<= div>
This is absolutely true, but see my point about t= he client control. Regardless, it is a much more difficult attack to carry = out. That is to intercept and rewrite a whole TCP connection Vs grabbing a = 0-RTT section and sending it again.=C2=A0
=C2=A0=
=C2=A0
What concerns me most here is that people= are clearly being confused by the TLS 1.3 draft into mis-understanding how= this interacts with 0-RTT. For example the X-header trick, to derive an id= empotency token from the binder, that one experimental deployment innovated= doesn't actually work because it doesn't protect against the DKG a= ttack. We're walking into rakes here.=C2=A0

Of course it doesn't protect agains= t the DKG attack, but nothing at that layer
actually does.
<= div>
This sounds like an issue with the current wording of th= e draft.=C2=A0 As I
mentioned, I believe we should be very clear = on what the developers should and
should not expect from TLS.=C2= =A0

Big = +1 :)=C2=A0
=C2=A0
So, in other words, since we'= re now just bargaining about the value of N,
operational concerns= are a fair game.

=
They're still not fair game imo, because there's a big = difference between permitting exactly
one duplicate, associat= ed with a client-driven retry, and permitting huge volumes of replays. They= enable different kinds of attacks.=C2=A0

<= /div>

Sure, but there's a space = between "one" and "huge amount".

It's not just quantitive, it&#= 39;s qualitative too. But now I'm duplicating myself more than once ;-)= =C2=A0
=C2=A0
Well in the real wor= ld, I think it'll be pervasive, and I even think it /should/ be. We sho= uld make 0-RTT that safe and remove the sharp edges.=C2=A0

Are you arguing that non-saf= e requests should be allowed to be sent via 0-RTT?
Because that a= ctually violates reasonable expectations of security guarantees
f= or TLS, and I do not believe that is acceptable.

I'm just saying that it absolu= tely will happen, and I don't think any kind of lawyering about the HTT= P spec and REST will change that. Folks use GETs for non-idempotent side-ef= fect-bearing APIs a lot. And those folks don't generally understand TLS= or have anything to do with it. I see no real chance of that changing and = it's a bit of a deceit for us to think that it's realistic that the= re will be these super careful 0-RTT deployments where everyone from the We= bserver administrator to the high-level application designer is coordinatin= g and fully aware of all of the implications. It crosses layers that are tr= aditionally quite far apart.=C2=A0

So with that in= mind, I argue that we have to make TLS transport as secure as possible by = default, while still delivering 0-RTT because that's such a beneficial = improvement.=C2=A0
=C2=A0
I do not believe that thi= s to be the case.=C2=A0 The DKG attack is an attack that allows
f= or a replay.=C2=A0

It's not. It permits a retry. The difference here is that = the client is in full control. It can decide to delay, to change a unique r= equest ID, or even not to retry at all. But the legitimate client generated= the first attempt, it can be signaled that it wasn't accepted, and the= n it generates the second attempt. If it really really needs to it can even= reason about the complicated semantics of the earlier request being possib= ly re-submitted later by an attacker.=C2=A0

That's already not acceptable for = a lot of applications -- and by enabling
0-RTT for non-safe HTTP = requests, we would be pulling the rug from under them.

Yep; but I think /this/ ri= sk is manageable and tolerable. Careful clients, like the token binding cas= e, can actually mitigate this. I've outlined the scheme. For careless c= lients, like browsers, they can mostly ignore this; since they retry so eas= ily anyway, it's no worse.=C2=A0

But there is = *no* proposed mitigation for replayable 0-RTT. So I don't think that= 9;s manageable. Just trying to make a data-driven decision. If someone pres= ents an alternative mitigation (besides forbidding replays), I'll chang= e my mind.=C2=A0
=C2=A0
Throttling POST requests is fine -- they shouldn't go= over 0-RTT, since they
are not idempotent.=C2=A0 Throttling GET = requests in this manner goes at odds with
RFC 7231.
<= /div>

Throttling GET requ= ests happens all of the time and is an important security and fairness meas= ure used by many deployed systems. 0-RTT would break it. That's not ok.= =C2=A0

I don't think it is at odds with RFC 72= 31 ... which also defines the 503 status code.=C2=A0
=


Incidentally,= guarantee C does solve the throttling problem -- if you get N
replays, you get promise of 1/(N+1) throttled resource available to you.<= /div>
Deployments which do this with GETs may want to deploy the measur= es to make N
very small.=C2=A0 Also, since they already keep trac= k of the state for throttling
purposes, they might add a strike r= egister on top of that.

One could implement a strike register like that, in the sam= e way as a coordinated throttling system, they have some things in common. = Though it crosses layers. =C2=A0

<= div>I'm all for bounded replay protection, with the bounds being 1 ;-)= =C2=A0

= Why not 2?=C2=A0 What is the difference between 1 and 2? =C2=A02 and 3? =C2= =A03 and 24?=C2=A0 None
of the proposed attacks distinguishes 1 r= eplay and N replays in qualitative
ways (as opposed to giant sema= ntic leap between 0 and 1 replay); only in how
much damage you ca= n do, or how much information you can extract from the side
chann= el.

Yo= u keep discarding my points about client control and focusing just on the n= umber; but there quantitative and qualitative differences. That kind of arg= ument isn't very productive and doesn't move us forward.=C2=A0 But = I've answered above too.=C2=A0

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


--001a11490b9a7dd4f00550ef2713-- From nobody Thu Jun 1 23:21:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAD6F12956B for ; Thu, 1 Jun 2017 23:21:00 -0700 (PDT) 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=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 gnn8yObJYnPm for ; Thu, 1 Jun 2017 23:20:59 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::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 D84441294E6 for ; Thu, 1 Jun 2017 23:20:58 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id r66so15702991yba.2 for ; Thu, 01 Jun 2017 23:20:58 -0700 (PDT) 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=QVYT7VS3ZhAy/REUNCxEmXX2O8qpajyFDX8VcmMAlaE=; b=wl2s74k8loDQW8lfYnjtbWNTzZgg6lanSnzSQoCVu3ZNZUHnsX++Bv9MxaDCe7UO3z 42sNYyIW+ACqn2xu6Q6OFvfS/H6JZRf7C5sLRtW3Q2LXjhcdMNANCFl2Y0cipxg45kU8 RP8YK7pVhZCZU5B3FvVk1f9sqJRYAC03mw2nQUBF3HDYKzrNv+OksCW9E2AgDXSmHKMR XRCdAznDbWE5O6PHxrMEEsRLC4NvL6mXu/qeWUq7XUvIDCGnXvTplq+kZK5tUBvnWnYG nLQlFaZksu2Y2FmaEWqw/I8JfhDTO1FtuKZfkCV6HeBx6ZG37qE37mvNH4oNzpRUDmlq Qcdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QVYT7VS3ZhAy/REUNCxEmXX2O8qpajyFDX8VcmMAlaE=; b=t3fxkiuZpqnkzQbo0IxoLVxVY+RYL0NDcfCw8ZX5GTB494y56eqbd0bECgbI8nv2NS 2vWMwiUgkYefmd4TdSfKWAEOI6hMhWe3h0Yyf1MTnvsjWqlwc2U5a0SNNjFUtOaoXC/x 3pb5lyNZshemjFzvwbxxSFPw2SuWDZRNA5BIkvg2guCjzrQi8TwDJrhY6TdWtdiTlTHY qxEm7YRQE7K8DnUOxelviG8NqbSVJyLL12tLMW5QQTyrBh8mYuJ4UQeh7HUQ/Xwv1G8H CLSb4FG4X/J66d245IWOqB+7XhSntjs3cSiGW+Taz62PoxT0zMHifGPX63CfAJakSvJL +djg== X-Gm-Message-State: AODbwcAD+q2oS3A+0ON/enaDFAZ5v0vD1YucasHsFw5wYMKkkb5st4Sg /pgm8hP1IdH0R4ZUD7U72GpZriEQLdc0 X-Received: by 10.37.170.98 with SMTP id s89mr21231935ybi.19.1496384457824; Thu, 01 Jun 2017 23:20:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.93.70 with HTTP; Thu, 1 Jun 2017 23:20:56 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Thu, 1 Jun 2017 23:20:56 -0700 Message-ID: To: Eric Rescorla Cc: Victor Vasiliev , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19ad5c0f06f20550f428b9" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 06:21:01 -0000 --94eb2c19ad5c0f06f20550f428b9 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 5:22 PM, Eric Rescorla wrote: > I've just gone through this thread and I'm having a very hard time > understanding what the actual substantive argument is about. > > Let me lay out what I think we all agree on. > This is a good summary, I just have a few clarifications ... > 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause > connection failures) then a DKG-style attack where the client > replays the 0-RTT data in 1-RTT is possible. > This isn't what I call a replay. It's a second request, but the client is control of it. That distinction matters because the client can modify it if it needs to be unique in some way and that turns out to be important for some cases. 2. Because of point #1, applications must implement some form > of replay-safe semantics. > Yep; though note that in some cases those replay-safe semantics themselves actually depend on uniquely identifiable requests. For example a protocol that depends on client-side-versioning, or the token-binding case. > 3. Allowing the attacker to generate an arbitrary number of 0-RTT > replays without client intervention is dangerous even if > the application implements replay-safe semantics. > Yep. > 4. If implemented properly, both a single-use ticket and a > strike-register style mechanism make it possible to limit > the number of 0-RTT copies which are processed to 1 within > a given zone (where a zone is defined as having consistent > storage), so the number of accepted copies of the 0-RTT > data is N where N is the number of zones. > This is much better than the total anarchy of allowing completely unlimited replay, and it does reduce the risk for side-channels, throttles etc, but I wouldn't consider it a proper implementation or secure. Importantly it gets us back to a state where clients may have no control over a deterministic outcome. Some clients need idempotency tokens that are consistent for duplicate requests, this approach works ok then. Other kinds of clients also need tokens that are unique to each request attempt, this approach doesn't work ok in that case. That's the qualitative difference. I'd also add that the suggested optimization here is clearly to support globally resumable session tickets that are not scoped to a single site. That's a worthy goal; but it's unfortunate that in the draft design it also means that 0-RTT sections would be globally scoped. That's seems bad to me because it's so hostile to forward secrecy, and hostile to protecting the most critical user-data. What's the point of having FS for everything except the requests, where the auth details often are, and which can usually be used to generate the response? Synchronizing keys that can de-cloak an arbitrary number of such sessions to many data centers spread out across the world, seems just so defeating. I realize that it's common today, I've built such systems, but at some point we have to decide that FS either matters or it doesn't. Are users and their security auditors really going to live with that? What is the point of rolling out ECDHE so pervasively only to undo most of the benefit? Maybe a lot of this dilemma could be avoided if the the PSKs that can be used for regular resumption and for 0-RTT encryption were separate, with the latter being scoped smaller and with use-at-most-once semantics. 5. Implementing the level of coherency to get #4 is a pain. > > 6. If you bind each ticket to a given zone, then you can > get limit the number of accepted 0-RTT copies to 1 > (for that zone) and accepted 1-RTT copies to 1 (because > of the DKG attack listed above). > Yep! Agreed :) -- Colm --94eb2c19ad5c0f06f20550f428b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Jun 1, 2017 at 5:22 PM, Eric Rescorla <ekr@rtfm.com> = wrote:
I've jus= t gone through this thread and I'm having a very hard time
un= derstanding what the actual substantive argument is about.

Let me lay out what I think we all agree on.

This is a good summary, I just have a few clarificat= ions ...
=C2=A0
1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause
=C2=A0 =C2=A0connection failures) then a DKG-style attack where the c= lient
=C2=A0 =C2=A0replays the 0-RTT data in 1-RTT is possible.

This isn't what I call a rep= lay. It's a second request, but the client is control of it. That disti= nction matters because the client can modify it if it needs to be unique in= some way and that turns out to be important for some cases.=C2=A0

2. Because= of point #1, applications must implement some form
=C2=A0 =C2=A0= of replay-safe semantics.

Yep; = though note that in some cases those replay-safe semantics themselves actua= lly depend on uniquely identifiable requests. For example a protocol that d= epends on client-side-versioning, or the token-binding case.=C2=A0
=C2=A0
3. Allow= ing the attacker to generate an arbitrary number of 0-RTT
=C2=A0 = =C2=A0replays without client intervention is dangerous even if
= =C2=A0 =C2=A0the application implements replay-safe semantics.
<= /blockquote>

Yep.
=C2=A0
4. If implemented properly, both a sin= gle-use ticket and a
=C2=A0 =C2=A0strike-register style mechanism= make it possible to limit
=C2=A0 =C2=A0the number of 0-RTT copie= s which are processed to 1 within
=C2=A0 =C2=A0a given zone (wher= e a zone is defined as having consistent
=C2=A0 =C2=A0storage), s= o the number of accepted copies of the 0-RTT
=C2=A0 =C2=A0data is= N where N is the number of zones.

<= div>This is much better than the total anarchy of allowing completely unlim= ited replay, and it does reduce the risk for side-channels, throttles etc, = but I wouldn't consider it a proper implementation or secure. Important= ly it gets us back to a state where clients may have no control over a dete= rministic outcome.=C2=A0

Some clients need idempot= ency tokens that are consistent for duplicate requests, this approach works= ok then. Other kinds of clients also need tokens that are unique to each r= equest attempt, this approach doesn't work ok in that case. That's = the qualitative difference.=C2=A0

I'd also add= that the suggested optimization here is clearly to support globally resuma= ble session tickets that are not scoped to a single site. That's a wort= hy goal; but it's unfortunate that in the draft design it also means th= at 0-RTT sections would be globally scoped. That's seems bad to me beca= use it's so hostile to forward secrecy, and hostile to protecting the m= ost critical user-data. What's the point of having FS for everything ex= cept the requests, where the auth details often are, and which can usually = be used to generate the response? Synchronizing keys that can de-cloak an a= rbitrary number of such sessions to many data centers spread out across the= world, seems just so defeating. I realize that it's common today, I= 9;ve built such systems, but at some point we have to decide that FS either= matters or it doesn't. Are users and their security auditors really go= ing to live with that? What is the point of rolling out ECDHE so pervasivel= y only to undo most of the benefit?

Maybe a lot of= this dilemma could be avoided if the the PSKs that can be used for regular= resumption and for 0-RTT encryption were separate, with the latter being s= coped smaller and with use-at-most-once semantics.=C2=A0

5. Implementing the = level of coherency to get #4 is a pain.

6. If you = bind each ticket to a given zone, then you can
=C2=A0 =C2=A0get l= imit the number of accepted 0-RTT copies to 1
=C2=A0 =C2=A0(for t= hat zone) and accepted 1-RTT copies to 1 (because
=C2=A0 =C2=A0of= the DKG attack listed above).

= Yep! Agreed :)

--
Colm
--94eb2c19ad5c0f06f20550f428b9-- From nobody Fri Jun 2 00:57:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB45C13148E for ; Fri, 2 Jun 2017 00:57:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 qsuq9fWK7RZQ for ; Fri, 2 Jun 2017 00:57:24 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 9519C129B62 for ; Fri, 2 Jun 2017 00:57:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id A03C620FEC; Fri, 2 Jun 2017 10:57:21 +0300 (EEST) 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 SEZBfzK2BpWP; Fri, 2 Jun 2017 10:57:21 +0300 (EEST) 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 6D08E2318; Fri, 2 Jun 2017 10:57:21 +0300 (EEST) Date: Fri, 2 Jun 2017 10:57:18 +0300 From: Ilari Liusvaara To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20170602075718.GA19666@LK-Perkele-V2.elisa-laajakaista.fi> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 07:57:29 -0000 On Thu, Jun 01, 2017 at 11:20:56PM -0700, Colm MacCárthaigh wrote: > > Maybe a lot of this dilemma could be avoided if the the PSKs that can be > used for regular resumption and for 0-RTT encryption were separate, with > the latter being scoped smaller and with use-at-most-once semantics. The problem here is that the scoping rules can be impossible for the client to understand (there is possibly anycast involved!) And also, more serious problem: I thought that server could send tickets that can't be used for 0-RTT. And this was true a few drafts back, but now it seems to have gotten lost (at least I can't find the appropriate requirements). This is a problem, because it forces any server that implements tickets to deal with at least ignoring 0-RTT (trial decryptions!). Which is complexity that I rather not have in servers that don't truly implement 0-RTT. -Ilari From nobody Fri Jun 2 01:43:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 105EE127A91; Fri, 2 Jun 2017 01:43:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 lWQZHB6t-DyV; Fri, 2 Jun 2017 01:43:06 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2D8412E042; Fri, 2 Jun 2017 01:43:05 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 083C458C4F7; Fri, 2 Jun 2017 10:43:01 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id D098CB0C189; Fri, 2 Jun 2017 10:43:00 +0200 (CEST) Date: Fri, 2 Jun 2017 10:43:00 +0200 From: Toerless Eckert To: Benoit Claise Cc: "ops-dir@ietf.org" , ops-chairs@ietf.org, "ops-ads@ietf.org" , "sec-ads@ietf.org" , tls@ietf.org Message-ID: <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> Reply-To: tls@ietf.org References: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 08:43:08 -0000 Thanks, Benoit [hope it's ok. to cross-port and redirect replies to TLS] I have not followed TLS 1.3 in detail, so a quick question first: Will TLS 1.3 still permit servers to send their certificate and/or SNI in the clear as an option or will it force server operators to encrypt either/or ? If it does not permit server applications to indicate what to encrypt, then i would really love to know which shared web-hosters did explicitly express support for TLS 1.3. Use case: (i can't believe this hasn't been discussed _forever_, but i do not subscribe to TLS...) Operators of "client-side" networks want to be able to enforce policies which "web-services" their clients can communicate with. As soon as the IP address used to host a web-service runs multiple web-services (domain-names), this is today done by inspecting the TLS 1.2 server certificate or SNI. Web hosters whose services do share IP addresses across domain name should be very interested to ensure such inspection works, because else a single misbehaving web-service they host will easily cause all their web-services to be blacklisted by any of the varied organizations that create blacklists: because blacklisting can then only be applied on a per-IP address. Of course, IPv6 could make this need somewhat obsolete because there should be no reason to share IPv6 addresses across domain-names, but i am not aware what todays common practice are with IPv6 in this respect. Cheers Toerless On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote: > Dear all, > > You should be aware that the TLS list is debating encrypting SNI so > that the host name cannot be seen from TLS sessions. > https://www.ietf.org/mail-archive/web/tls/current/msg23251.htm > > If you're aware of valid (valid in the IETF-sense) operational > practices that require the host name visible, we should enter the > debate. > > Regards, Benoit From nobody Fri Jun 2 01:57:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4564B127B31 for ; Fri, 2 Jun 2017 01:57:37 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 2c8SYzZfsGud for ; Fri, 2 Jun 2017 01:57:35 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 3BEC112706D for ; Fri, 2 Jun 2017 01:57:35 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3916720440 for ; Fri, 2 Jun 2017 11:57:34 +0300 (EEST) 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 Lgt3gPwiLlN7 for ; Fri, 2 Jun 2017 11:57:34 +0300 (EEST) 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 059DA2313 for ; Fri, 2 Jun 2017 11:57:34 +0300 (EEST) Date: Fri, 2 Jun 2017 11:57:30 +0300 From: Ilari Liusvaara To: tls@ietf.org Message-ID: <20170602085730.GB19666@LK-Perkele-V2.elisa-laajakaista.fi> References: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 08:57:37 -0000 On Fri, Jun 02, 2017 at 10:43:00AM +0200, Toerless Eckert wrote: > Thanks, Benoit > > [hope it's ok. to cross-port and redirect replies to TLS] > > I have not followed TLS 1.3 in detail, so a quick question first: > > Will TLS 1.3 still permit servers to send their certificate and/or SNI in the clear as an option or > will it force server operators to encrypt either/or ? If it does not permit server applications > to indicate what to encrypt, then i would really love to know which shared web-hosters did > explicitly express support for TLS 1.3. SNI is always in the clear, certificates are always encrypted. There was lots of discussion about SNI encryption, but encrypting SNI turned out to be too nasty. > Web hosters whose services do share IP addresses across domain name should be very interested to > ensure such inspection works, because else a single misbehaving web-service they host will easily > cause all their web-services to be blacklisted by any of the varied organizations that create > blacklists: because blacklisting can then only be applied on a per-IP address. At least GSB can blacklist even at page granularity (I have seen such blacklisting, in that case due to images being loaded from "shady" sites.) -Ilari From nobody Fri Jun 2 03:16:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F47612EB1D for ; Fri, 2 Jun 2017 03:16:08 -0700 (PDT) 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=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 ky6dSstplGR7 for ; Fri, 2 Jun 2017 03:16:07 -0700 (PDT) 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 9EBAC12EB26 for ; Fri, 2 Jun 2017 03:16:03 -0700 (PDT) Received: by mail-wm0-x22b.google.com with SMTP id b84so20078711wmh.0 for ; Fri, 02 Jun 2017 03:16:03 -0700 (PDT) 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=IoAE/OUPnfbS71im5mP1QXyapBn14Kh6Lz9X+NEAIao=; b=TOHr5L8ZRn8irWJvpOLv3nkUd/iWhc7WZ6pZIxyzyt+d2zDWIzD4Y7l/FWyyLIN8M5 KiCK85bTAswTpHkBZgIRL3NLCTefji5+JYLjex81HhXIXodM55dVvKz2ccRyneh7+0g8 ONJD+fKkPxlEp4elAEnAn0hT2ILE/LGmAF/8rXJWfQ1VerImsLpd8AEb0icGTJiACRL9 46NoZsFTbW2spKBFs+GlTnLcVBancXKGZ7Y5VM+yOhfYhGKzlj+P+V2bAmKX6HwgiyMo PspVG1Qgkcnb3PXj1bwO/Ch3XgepNgTaGf4juaJWbKqZ7bgMUvOtHuzW5SnsK8OxVuoW HZwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=IoAE/OUPnfbS71im5mP1QXyapBn14Kh6Lz9X+NEAIao=; b=ovqEDMMrzLO6zPVEfSze7V0KyMXkk7q9a6Ni8OTbLVoXyPM6aio7IYSlA5+V0KLGEn Xmwtlmo1XWz+Odq0cdXpsV+cz/GXOzMnq6ysZGYlI7h0DNfW2pztVi8mXNDKo5rwB5Bb UY3Xt6+9m3UVBF71vpmWyRNOxtBARAJQFn7BbMqgTa1m9WOgdVsfOrwJB9BaItf2+cDx 2MRCqJI0+rY4zqfMzVe4ZMT2+H/Zh+toaWKSiCgnbqmVtHEjEzoPmrVEZQfC6FhSkBcP Gn1k4ZqeqcgXdtRRgPO2Z2CnIfvVS3xDALzTgdI/72/DlTwfkKgO5RY1Jb4oTPkwRi27 EycQ== X-Gm-Message-State: AODbwcD6oImUdbxLlyAuatLrupMtGGqU4m8oW3DLqVOg9W2UAUVY7fOB YzW8m52VoZ9O4oTXxFvQPx6JhmU/cgugAzI= X-Received: by 10.223.170.195 with SMTP id i3mr5547649wrc.49.1496398561717; Fri, 02 Jun 2017 03:16:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.109.82 with HTTP; Fri, 2 Jun 2017 03:16:01 -0700 (PDT) In-Reply-To: <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> References: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> From: Richard Barnes Date: Fri, 2 Jun 2017 13:16:01 +0300 Message-ID: To: "" Cc: Benoit Claise , "ops-dir@ietf.org" , "ops-ads@ietf.org" , "sec-ads@ietf.org" , ops-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1cbbc0b6c7090550f770ee" Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 10:16:08 -0000 --94eb2c1cbbc0b6c7090550f770ee Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 11:43 AM, Toerless Eckert wrote: > Thanks, Benoit > > [hope it's ok. to cross-port and redirect replies to TLS] > > I have not followed TLS 1.3 in detail, so a quick question first: > > Will TLS 1.3 still permit servers to send their certificate and/or SNI in > the clear as an option or > will it force server operators to encrypt either/or ? If it does not > permit server applications > to indicate what to encrypt, then i would really love to know which shared > web-hosters did > explicitly express support for TLS 1.3. > > Use case: (i can't believe this hasn't been discussed _forever_, but i do > not subscribe to TLS...) > > Operators of "client-side" networks want to be able to enforce policies > which "web-services" > their clients can communicate with. Operators trying to do this by inspecting TLS (and not decrypting) are going to have a bad time anyway. With HTTP/2 connection coalescing, even if they can see the certificate, the actual HTTP request could be for any name in the certificate. So there's nothing really gained by exposing the certificate. --Richard > As soon as the IP address used to host a web-service runs > multiple web-services (domain-names), this is today done by inspecting the > TLS 1.2 server certificate > or SNI. > > Web hosters whose services do share IP addresses across domain name should > be very interested to > ensure such inspection works, because else a single misbehaving > web-service they host will easily > cause all their web-services to be blacklisted by any of the varied > organizations that create > blacklists: because blacklisting can then only be applied on a per-IP > address. > > Of course, IPv6 could make this need somewhat obsolete because there > should be no reason to > share IPv6 addresses across domain-names, but i am not aware what todays > common practice are with IPv6 > in this respect. > > Cheers > Toerless > > On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote: > > Dear all, > > > > You should be aware that the TLS list is debating encrypting SNI so > > that the host name cannot be seen from TLS sessions. > > https://www.ietf.org/mail-archive/web/tls/current/msg23251.htm > > > > If you're aware of valid (valid in the IETF-sense) operational > > practices that require the host name visible, we should enter the > > debate. > > > > Regards, Benoit > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c1cbbc0b6c7090550f770ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 2, 2017 at 11:43 AM, Toerless Eckert <= tte@cs.fau.de> wrote:
Thanks, Benoit

[hope it's ok. to cross-port and redirect replies to TLS]

I have not followed TLS 1.3 in detail, so a quick question first:

Will TLS 1.3 still permit servers to send their certificate and/or SNI in t= he clear as an option or
will it force server operators to encrypt either/or ? If it does not permit= server applications
to indicate what to encrypt, then i would really love to know which shared = web-hosters did
explicitly express support for TLS 1.3.

Use case: (i can't believe this hasn't been discussed _forever_, bu= t i do not subscribe to TLS...)

Operators of "client-side" networks want to be able to enforce po= licies which "web-services"
their clients can communicate with.

Operat= ors trying to do this by inspecting TLS (and not decrypting) are going to h= ave a bad time anyway.=C2=A0 With HTTP/2 connection coalescing, even if the= y can see the certificate, the actual HTTP request could be for any name in= the certificate.=C2=A0 So there's nothing really gained by exposing th= e certificate.

--Richard

=C2=A0
As soon as the IP addres= s used to host a web-service runs
multiple web-services (domain-names), this is today done by inspecting the = TLS 1.2 server certificate
or SNI.

Web hosters whose services do share IP addresses across domain name should = be very interested to
ensure such inspection works, because else a single misbehaving web-service= they host will easily
cause all their web-services to be blacklisted by any of the varied organiz= ations that create
blacklists: because blacklisting can then only be applied on a per-IP addre= ss.

Of course, IPv6 could make this need somewhat obsolete because there should= be no reason to
share IPv6 addresses across domain-names, but i am not aware what todays co= mmon practice are with IPv6
in this respect.

Cheers
=C2=A0 =C2=A0 Toerless

On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote:
> Dear all,
>
> You should be aware that the TLS list is debating encrypting SNI so > that the host name cannot be seen from TLS sessions.
> https://www.ietf.org/mail-ar= chive/web/tls/current/msg23251.htm
>
> If you're aware of valid (valid in the IETF-sense) operational
> practices that require the host name visible, we should enter the
> debate.
>
> Regards, Benoit

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

--94eb2c1cbbc0b6c7090550f770ee-- From nobody Fri Jun 2 03:32:07 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520D4129503; Fri, 2 Jun 2017 03:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 2oxjp29sQJH5; Fri, 2 Jun 2017 03:31:56 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E727012EB0F; Fri, 2 Jun 2017 03:31:55 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id B8C9758C4B0; Fri, 2 Jun 2017 12:31:51 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A3757B0C18F; Fri, 2 Jun 2017 12:31:51 +0200 (CEST) Date: Fri, 2 Jun 2017 12:31:51 +0200 From: Toerless Eckert To: Richard Barnes Cc: "" , Benoit Claise , "ops-dir@ietf.org" , "ops-ads@ietf.org" , "sec-ads@ietf.org" , ops-chairs@ietf.org Message-ID: <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de> References: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 10:31:58 -0000 On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote: > Operators trying to do this by inspecting TLS (and not decrypting) are > going to have a bad time anyway. With HTTP/2 connection coalescing, even > if they can see the certificate, the actual HTTP request could be for any > name in the certificate. So there's nothing really gained by exposing the > certificate. If a web service hoster does not provide any useful demultiplexer then it can of course not expect not to get blacklisted across services. Is it not already common practice to assign separate certificates to separate "web customers" ? --Toerless > --Richard > > > > > As soon as the IP address used to host a web-service runs > > multiple web-services (domain-names), this is today done by inspecting the > > TLS 1.2 server certificate > > or SNI. > > > > Web hosters whose services do share IP addresses across domain name should > > be very interested to > > ensure such inspection works, because else a single misbehaving > > web-service they host will easily > > cause all their web-services to be blacklisted by any of the varied > > organizations that create > > blacklists: because blacklisting can then only be applied on a per-IP > > address. > > > > Of course, IPv6 could make this need somewhat obsolete because there > > should be no reason to > > share IPv6 addresses across domain-names, but i am not aware what todays > > common practice are with IPv6 > > in this respect. > > > > Cheers > > Toerless > > > > On Thu, Jun 01, 2017 at 04:38:46PM +0200, Benoit Claise wrote: > > > Dear all, > > > > > > You should be aware that the TLS list is debating encrypting SNI so > > > that the host name cannot be seen from TLS sessions. > > > https://www.ietf.org/mail-archive/web/tls/current/msg23251.htm > > > > > > If you're aware of valid (valid in the IETF-sense) operational > > > practices that require the host name visible, we should enter the > > > debate. > > > > > > Regards, Benoit > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > -- --- tte@cs.fau.de From nobody Fri Jun 2 05:03:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDF38129AE5; Fri, 2 Jun 2017 05:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.299 X-Spam-Level: X-Spam-Status: No, score=-4.299 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_H2=-2.8, 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=sleevi.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 BVECmNVNq4t3; Fri, 2 Jun 2017 05:03:43 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7BA127010; Fri, 2 Jun 2017 05:03:43 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 1108130002B29; Fri, 2 Jun 2017 05:03:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=mime-version :in-reply-to:references:from:date:message-id:subject:to:cc :content-type; s=sleevi.com; bh=z5wOxWdcM2WW6ehzlopwH3TKPUE=; b= KSzYs//NxuPRvFxE5j6oVQyznvgW3HbUEzLzSu4qigYAl/tJC27bG+vNZNcFEySE 6XocPLWSC0230ej6uZ+oQ4/GJe/B3GzsQKtKnZowIwaAyoy5BSqph1yRNgqj4iby zjQPzGz/WfwhEkMy6/XlWrq8uv9xHUtlxAjpKRVrT0A= Received: from mail-wm0-f44.google.com (mail-wm0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: ryan@sleevi.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id CC14830002B25; Fri, 2 Jun 2017 05:03:42 -0700 (PDT) Received: by mail-wm0-f44.google.com with SMTP id 7so23308116wmo.1; Fri, 02 Jun 2017 05:03:42 -0700 (PDT) X-Gm-Message-State: AODbwcDHz8jIVsSKRUbsw5KIsfsNXpgISxbL4e8j1BGBzDD5AmcDnolD grefahvpjG0d7ORoxovLhOva+Xv8rw== X-Received: by 10.223.171.24 with SMTP id q24mr226538wrc.89.1496405021261; Fri, 02 Jun 2017 05:03:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.128.164 with HTTP; Fri, 2 Jun 2017 05:03:40 -0700 (PDT) In-Reply-To: <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de> References: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de> From: Ryan Sleevi Date: Fri, 2 Jun 2017 08:03:40 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Toerless Eckert Cc: Richard Barnes , "ops-dir@ietf.org" , "" , Benoit Claise , "sec-ads@ietf.org" , "ops-ads@ietf.org" , ops-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c1b54d4bb89540550f8f14a" Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 12:03:45 -0000 --94eb2c1b54d4bb89540550f8f14a Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 6:31 AM, Toerless Eckert wrote: > On Fri, Jun 02, 2017 at 01:16:01PM +0300, Richard Barnes wrote: > > Operators trying to do this by inspecting TLS (and not decrypting) are > > going to have a bad time anyway. With HTTP/2 connection coalescing, even > > if they can see the certificate, the actual HTTP request could be for any > > name in the certificate. So there's nothing really gained by exposing > the > > certificate. > > If a web service hoster does not provide any useful demultiplexer then it > can of course not > expect not to get blacklisted across services. Is it not already common > practice to assign > separate certificates to separate "web customers" ? > No. It's typically the opposite. --94eb2c1b54d4bb89540550f8f14a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 2, 2017 at 6:31 AM, Toerless Eckert <<= a href=3D"mailto:tte@cs.fau.de" target=3D"_blank">tte@cs.fau.de> wrote:
On Fri, Jun 0= 2, 2017 at 01:16:01PM +0300, Richard Barnes wrote:
> Operators trying to do this by inspecting TLS (and not decrypting) are=
> going to have a bad time anyway.=C2=A0 With HTTP/2 connection coalesci= ng, even
> if they can see the certificate, the actual HTTP request could be for = any
> name in the certificate.=C2=A0 So there's nothing really gained by= exposing the
> certificate.

If a web service hoster does not provide any useful demultiplexer th= en it can of course not
expect not to get blacklisted across services. Is it not already common pra= ctice to assign
separate certificates to separate "web customers" ?

No. It's typically the opposite.=C2=A0
--94eb2c1b54d4bb89540550f8f14a-- From nobody Fri Jun 2 06:28:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AB5612EB94; Fri, 2 Jun 2017 06:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ld8XoVly1tJt; Fri, 2 Jun 2017 06:28:37 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13AB012EB86; Fri, 2 Jun 2017 06:28:37 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id C4A7258C4B0; Fri, 2 Jun 2017 15:28:33 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id A3A23B0C195; Fri, 2 Jun 2017 15:28:33 +0200 (CEST) Date: Fri, 2 Jun 2017 15:28:33 +0200 From: Toerless Eckert To: Ryan Sleevi Cc: Richard Barnes , "ops-dir@ietf.org" , "" , Benoit Claise , "sec-ads@ietf.org" , "ops-ads@ietf.org" , ops-chairs@ietf.org Message-ID: <20170602132833.GE12522@faui40p.informatik.uni-erlangen.de> References: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 13:28:38 -0000 On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote: > > If a web service hoster does not provide any useful demultiplexer then it > > can of course not > > expect not to get blacklisted across services. Is it not already common > > practice to assign > > separate certificates to separate "web customers" ? > > No. It's typically the opposite. Thanks. Btw: does TLS 1.3 mandate server side cert encryption or is this something server apps can decide ? Just because shared web services may not yet leverage the ability to use certs to authenticate network connections well doesn't mean that that option should not be given to apps. And it would be sad if one would have to revert to older protocol options to have that functionality. Another candidate use case coming to mind eg: auditing tht is required in many eg: financial environments. In the past i have seen even the requirement for the whole data streams to be unencrypted for auditing. Maybe that market segment would also be able to get more privacy but maintain a relevant level of auditing if the auditing relevant class of information was visible via the cert. Cheers Toerless From nobody Fri Jun 2 06:59:44 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D843C129AEE for ; Fri, 2 Jun 2017 06:59:43 -0700 (PDT) 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 z1t3vPlYsbCq for ; Fri, 2 Jun 2017 06:59:42 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 20D8E12940C for ; Fri, 2 Jun 2017 06:59:42 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id 63so20911114ywr.0 for ; Fri, 02 Jun 2017 06:59:42 -0700 (PDT) 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=oQEsCtmfw6HjBRTQiND2CiNKHgZJ7hpbDo0FqTU1h0M=; b=03h9wVXdhVu+WbYWNAZ2tRStF4WFCPGtHq5Hs7QQosx26KK7fF/ccl7aMoA8BdoiHP qlN4bSCiY81y7xnjUfYHnMumeiz2JrwRaOIh4zFYJnWVYYTHB+makvhR4guqVDnTseBI c57e/AHti+nPBrfAA11fnq9p2U9qW/teoUKLpKo0BAoLanocyL+aOHo1YZBTu5mCXt2n BiE4qZ1mM9BtCix+sTs7W4jc9KxUOfhrXKK+HXZOJiERvJ06SXwotqDFCg14mcR0ckXd GMg9h8neFN/cerkFHVWLSmJ/iTjT4EVkL60TRv+5tCcDs1qs0cfX2AP7j1YjvBLzRA8I pEKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oQEsCtmfw6HjBRTQiND2CiNKHgZJ7hpbDo0FqTU1h0M=; b=l/HnriS22ErS8u+68HgDVP7NrIUvs9eYkjU5rmGDEvGPXh0oGGLuKRAdn7yk36LH5T szUzHPfwRXhaXMFPIg6UrLz2QVhi+pBM5/d9p7VGepfNJiBcRk5e2zVu2Rvvn1QsfnD0 s0z+DlYrHGPlJBQ3F4Is92ZXSJUUUYSRA9D+1EYDV+ZXN9cgL6CspXSwp3OgJFCVkOSz k8yllXdWnWiFOELtIn4vRKxjOuGxVPUgG9KiaHlMPh6o1uRL5Wjt6+8fc9PaZFIKwE58 EKO1Vd9S2eZDUgOklURIaFtMYMKUrrMIZuLLhrwBmnbZm7zO++wy5mAy20Y94ZZAWrZS Rpdw== X-Gm-Message-State: AODbwcCSoYczsoKfn7b+1Bv6a3sZ9opxNFGn13tCXL9BujWN4oOmfh4j PdTFO8ziw3MLmwW7cajX0WfwL2Iptcw9FRc= X-Received: by 10.13.212.1 with SMTP id w1mr5512339ywd.24.1496411981189; Fri, 02 Jun 2017 06:59:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.106.137 with HTTP; Fri, 2 Jun 2017 06:58:59 -0700 (PDT) In-Reply-To: <20170602075718.GA19666@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170602075718.GA19666@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 2 Jun 2017 06:58:59 -0700 Message-ID: To: Ilari Liusvaara Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114fb0f69485cd0550fa9072" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 13:59:44 -0000 --001a114fb0f69485cd0550fa9072 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable It's still there, in 4.6.1. "The sole extension currently defined for NewSessionTicket is =E2=80=9Cearl= y_data=E2=80=9D, indicating that the ticket may be used to send 0-RTT data (Section 4.2.9 )). It contains the following value:" -Ekr On Fri, Jun 2, 2017 at 12:57 AM, Ilari Liusvaara wrote: > On Thu, Jun 01, 2017 at 11:20:56PM -0700, Colm MacC=C3=A1rthaigh wrote: > > > > Maybe a lot of this dilemma could be avoided if the the PSKs that can b= e > > used for regular resumption and for 0-RTT encryption were separate, wit= h > > the latter being scoped smaller and with use-at-most-once semantics. > > The problem here is that the scoping rules can be impossible for the > client to understand (there is possibly anycast involved!) > > > And also, more serious problem: I thought that server could send > tickets that can't be used for 0-RTT. And this was true a few drafts > back, but now it seems to have gotten lost (at least I can't find > the appropriate requirements). This is a problem, because it forces > any server that implements tickets to deal with at least ignoring > 0-RTT (trial decryptions!). Which is complexity that I rather not > have in servers that don't truly implement 0-RTT. > > > > -Ilari > --001a114fb0f69485cd0550fa9072 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's still there, in 4.6.1.

"T= he sole extension currently defined for NewSessionTicket is=20 =E2=80=9Cearly_data=E2=80=9D, indicating that the ticket may be used to sen= d 0-RTT data (Section 4.2.9)). It contains the following v= alue:"

-Ekr


On Fri, Jun 2, 2017 at 12:57 A= M, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:<= br>
On Thu, Jun 01, 2017 at 11:20:56PM = -0700, Colm MacC=C3=A1rthaigh wrote:
>
> Maybe a lot of this dilemma could be avoided if the the PSKs that can = be
> used for regular resumption and for 0-RTT encryption were separate, wi= th
> the latter being scoped smaller and with use-at-most-once semantics.
The problem here is that the scoping rules can be impossible for the=
client to understand (there is possibly anycast involved!)


And also, more serious problem: I thought that server could send
tickets that can't be used for 0-RTT. And this was true a few drafts back, but now it seems to have gotten lost (at least I can't find
the appropriate requirements). This is a problem, because it forces
any server that implements tickets to deal with at least ignoring
0-RTT (trial decryptions!). Which is complexity that I rather not
have in servers that don't truly implement 0-RTT.



-Ilari

--001a114fb0f69485cd0550fa9072-- From nobody Fri Jun 2 07:17:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1B812EBC0 for ; Fri, 2 Jun 2017 07:17:20 -0700 (PDT) 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 U0a4f5to-GGy for ; Fri, 2 Jun 2017 07:17:19 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 1F23512EBB0 for ; Fri, 2 Jun 2017 07:17:17 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l74so33656445ywe.2 for ; Fri, 02 Jun 2017 07:17:17 -0700 (PDT) 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=XrE8VNGcbrN6o3C3shGxvrT/bSf3KGlImsntOcGy0II=; b=KNCwvaypzk7RKMPWP20PsZvSSY+kfuLd8U9ievzDNBY6B0WBpz1Av2uNZW0t3iloHx MhaIfEAfRj127NMUXH/YQttD+uvZmTn1Qe1JoZC8fbv1bUk1A7IeSPPW6Pktr8m+lDln cIu2NdoR1DrADLENXN9/t/u3zLXE8fa0c7OHdGcX2btmeNaqZ2/U+0QF6FcDsgTn1uXB 5bjEfB/xfOUrYJDXN0yDvPuzAZ+fKTqTiofMcLSjKzQUmbq7WoTJRmZ0MY6pZEXWexjq tLwzQdcuM3xQvXr8Ms+jGa6J5zvDESUsNyeldmboBJcKz3noCLjOVeh5zH4B36Cx0gq5 Iohg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XrE8VNGcbrN6o3C3shGxvrT/bSf3KGlImsntOcGy0II=; b=nntEmc1wii6ULiq4tdTiJhFgRSRSp6xshHhR1/IO94EwTRd31tmuyZLCmg/+28UAJ4 +zqrduc3z5mlaTz2Wbcf06jbd9IOCTYZMXdUPxkUunXHDxGqxxi74wgqjh2JRDayE2+j VKq6j21nLuFJ6E/8tSGpBNYPbeyvUCkYObOZdx3u8GS0n70UIjIMp6aWpETj81ttYjEk cGJqaeCD10mL5v9gyHoDKfEm1EA9fE+WO1X3VI90/7T2idSWFAzB0j0TNsp4ecGae0kt go9ZcYcSnpXDu6LaBbu2mla2ID37sCONf/Wz+KWiW7+Jsv5hkXCdYePonQ9ZCep5//GL 9JAQ== X-Gm-Message-State: AODbwcCjq1PjrrsqtQ0X2/f8UZNtGCE3kXw7VgAdPLcMqu2eJ+Ra9u/o SHRccqtthqNn/PuqqaVzSyDm84h1J2jJ X-Received: by 10.129.97.193 with SMTP id v184mr6093502ywb.270.1496413036341; Fri, 02 Jun 2017 07:17:16 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.106.137 with HTTP; Fri, 2 Jun 2017 07:16:35 -0700 (PDT) In-Reply-To: <20170602132833.GE12522@faui40p.informatik.uni-erlangen.de> References: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de> <20170602132833.GE12522@faui40p.informatik.uni-erlangen.de> From: Eric Rescorla Date: Fri, 2 Jun 2017 07:16:35 -0700 Message-ID: To: Toerless Eckert Cc: Ryan Sleevi , Richard Barnes , "ops-dir@ietf.org" , "" , Benoit Claise , "sec-ads@ietf.org" , "ops-ads@ietf.org" , ops-chairs@ietf.org Content-Type: multipart/alternative; boundary="001a11490722781cac0550facff8" Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 14:17:20 -0000 --001a11490722781cac0550facff8 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 6:28 AM, Toerless Eckert wrote: > On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote: > > > If a web service hoster does not provide any useful demultiplexer then > it > > > can of course not > > > expect not to get blacklisted across services. Is it not already common > > > practice to assign > > > separate certificates to separate "web customers" ? > > > > No. It's typically the opposite. > > Thanks. > > Btw: does TLS 1.3 mandate server side cert encryption or is this something > server > apps can decide ? It mandates it. > Just because shared web services may not yet leverage the ability to > use certs to authenticate network connections well doesn't mean that that > option should not > be given to apps. And it would be sad if one would have to revert to older > protocol options > to have that functionality. > That functionality is illusory even now, because they are unable to determine that the server and the client are not colluding to lie about the server's identity. -Ekr --001a11490722781cac0550facff8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 2, 2017 at 6:28 AM, Toerless Eckert <<= a href=3D"mailto:tte@cs.fau.de" target=3D"_blank">tte@cs.fau.de> wrote:
On Fri, Jun 0= 2, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote:
> > If a web service hoster does not provide any useful demultiplexer= then it
> > can of course not
> > expect not to get blacklisted across services. Is it not already = common
> > practice to assign
> > separate certificates to separate "web customers" ?
>
> No. It's typically the opposite.

Thanks.

Btw: does TLS 1.3 mandate server side cert encryption or is this something = server
apps can decide ?

It mandates it.

=C2=A0
Just because sh= ared web services may not yet leverage the ability to
use certs to authenticate network connections well doesn't mean that th= at option should not
be given to apps. And it would be sad if one would have to revert to older = protocol options
to have that functionality.

That functi= onality is illusory even now, because they are unable to determine
that the server and the client are not colluding to lie about the server&= #39;s identity.

-Ekr

--001a11490722781cac0550facff8-- From nobody Fri Jun 2 07:21:44 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52FDC12EBA8 for ; Fri, 2 Jun 2017 07:21:42 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 HfcTKCzKLUah for ; Fri, 2 Jun 2017 07:21:40 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 88268128E19 for ; Fri, 2 Jun 2017 07:21:40 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id 127EF5FEC1; Fri, 2 Jun 2017 17:21:39 +0300 (EEST) 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 n7KL35GlFa5Z; Fri, 2 Jun 2017 17:21:38 +0300 (EEST) 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 D5F9E21C; Fri, 2 Jun 2017 17:21:38 +0300 (EEST) Date: Fri, 2 Jun 2017 17:21:36 +0300 From: Ilari Liusvaara To: Toerless Eckert Cc: "" Message-ID: <20170602142136.GA20535@LK-Perkele-V2.elisa-laajakaista.fi> References: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de> <20170602132833.GE12522@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20170602132833.GE12522@faui40p.informatik.uni-erlangen.de> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 14:21:42 -0000 On Fri, Jun 02, 2017 at 03:28:33PM +0200, Toerless Eckert wrote: > On Fri, Jun 02, 2017 at 08:03:40AM -0400, Ryan Sleevi wrote: > > > If a web service hoster does not provide any useful demultiplexer then it > > > can of course not > > > expect not to get blacklisted across services. Is it not already common > > > practice to assign > > > separate certificates to separate "web customers" ? > > > > No. It's typically the opposite. > > Thanks. > > Btw: does TLS 1.3 mandate server side cert encryption or is this something server > apps can decide ? It is required. Of server messages, TLS 1.3 only leaves ServerHello unencrypted. SH contains low-level connection parameters: - TLS version used - Server random value - Record protection / PRF algorithm used - DH key share (if DH is used). - PSK identity selected (if PSK is used). The certificate is sent in certificate message, which is always protected (encrypted). -Ilari From nobody Fri Jun 2 14:25:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6659F126D73 for ; Fri, 2 Jun 2017 14:25:58 -0700 (PDT) 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 73Mt2xwP_oxe for ; Fri, 2 Jun 2017 14:25:55 -0700 (PDT) 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 52B51124217 for ; Fri, 2 Jun 2017 14:25:55 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id l14so37571330ywk.1 for ; Fri, 02 Jun 2017 14:25:55 -0700 (PDT) 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=P232JNSnZiRMRx/xqDA5e1kWVJFppdB5Vl4J6Iew0cI=; b=l9VL8qeUAX79TpDeDHsEpQW/JX3PopXhD6schHzVfNyY/SpeSDYaXzBgJgWWgHX+QF vZHiBMHs58Yp5IHLfnuU+lmjUDGiYL06V2nwp/8NWONPvRat2x9J5IkhG/S6TZShoxMx 6xbwBMuFdtM0JjscF7Bok3WIE22pOVc3Kaf6kA1Yy3z+C/rYqsxyrTnTqGGSQvzKVjn0 4vYJGyGqsczbt+1UnGTXBhoiXGdekDwqAWoVhjjO8oqLmC5gn7s8h0OlqA6Lr0JQQKwG 3xoQxQODbhG3aIxtUOuohoXNLLtY90VPwTXmo/292i2AU9XVsE113tuZnksS7KhtzpiD 02+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P232JNSnZiRMRx/xqDA5e1kWVJFppdB5Vl4J6Iew0cI=; b=SwRZ0udkVdwhJdnyQxCp1Y3f0qvGzV09InMGeQIJGA8Lk3BfX8DZLQNKBsmOIVTi4X vfFbB3iUnXHT4XUh7yFaj4beRqWjADNo4/daRpYU4GadTLftaQjq8kF0rsFCHst67Aph c0yad+iBjyflM5yW3EKPdYgTbdUuCzlF2AVXNfdwiS9VQnzfC1DklfI2xMTSO8sN8VvP Ea3kGenBhsfssHcn51LAr17ATstnkzYBVKfHYBNw666FhGJge08kqaCk7LUaNyE4fXMJ +DacraT/c9Vnw/LDKfC5oP+PZB6IwDXTpuck7tMhTR+VDSm8yOeXxSJ0cZY6OmU/fRNo SfCg== X-Gm-Message-State: AODbwcDV9DhQjI58Rk1h6iSrMowVVjZNJWoiZcCUHycH3bocmgu9gcdN I7+V1/5DJhjN4/0ZYx2mmGopz1AmMJKl1Ln8+Q== X-Received: by 10.129.104.69 with SMTP id d66mr7165471ywc.74.1496438754535; Fri, 02 Jun 2017 14:25:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.106.137 with HTTP; Fri, 2 Jun 2017 14:25:13 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 2 Jun 2017 14:25:13 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Victor Vasiliev , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11490b9a64c26a055100cc4b" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 21:25:58 -0000 --001a11490b9a64c26a055100cc4b Content-Type: text/plain; charset="UTF-8" > > On Thu, Jun 1, 2017 at 5:22 PM, Eric Rescorla wrote: > > > 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause > > connection failures) then a DKG-style attack where the client > > replays the 0-RTT data in 1-RTT is possible. > > > > This isn't what I call a replay. It's a second request, but the client is > control of it. That distinction matters because the client can modify it if > it needs to be unique in some way and that turns out to be important for > some cases. Sure. For the sake of clarify, I'm going to suggest we call: - replay == the attacker re-sends the data with no interaction with the client - retransmission == the client re-sends (possibly with some slight changes) > > 4. If implemented properly, both a single-use ticket and a > > strike-register style mechanism make it possible to limit > > the number of 0-RTT copies which are processed to 1 within > > a given zone (where a zone is defined as having consistent > > storage), so the number of accepted copies of the 0-RTT > > data is N where N is the number of zones. > > > > This is much better than the total anarchy of allowing completely unlimited > replay, and it does reduce the risk for side-channels, throttles etc, but I > wouldn't consider it a proper implementation or secure. I'm not presently taking a position on whether this is secure or proper, or whatever. I'm just attempting to state the facts about how the system behaves. From this, I'm going to take that you agree with this statement. > > Maybe a lot of this dilemma could be avoided if the the PSKs that can be > used for regular resumption and for 0-RTT encryption were separate, with > the latter being scoped smaller and with use-at-most-once semantics. > > 5. Implementing the level of coherency to get #4 is a pain. > > > > 6. If you bind each ticket to a given zone, then you can > > get limit the number of accepted 0-RTT copies to 1 > > (for that zone) and accepted 1-RTT copies to 1 (because > > of the DKG attack listed above). > > > > Yep! Agreed :) Moving the text above to here: > Importantly it gets > us back to a state where clients may have no control over a deterministic > outcome. > > Some clients need idempotency tokens that are consistent for duplicate > requests, this approach works ok then. Other kinds of clients also need > tokens that are unique to each request attempt, this approach doesn't work > ok in that case. That's the qualitative difference. > > I'd also add that the suggested optimization here is clearly to support > globally resumable session tickets that are not scoped to a single site. > That's a worthy goal; but it's unfortunate that in the draft design it also > means that 0-RTT sections would be globally scoped. That's seems bad to me > because it's so hostile to forward secrecy, and hostile to protecting the > most critical user-data. What's the point of having FS for everything > except the requests, where the auth details often are, and which can > usually be used to generate the response? Synchronizing keys that can > de-cloak an arbitrary number of such sessions to many data centers spread > out across the world, seems just so defeating. I realize that it's common > today, I've built such systems, but at some point we have to decide that FS > either matters or it doesn't. Are users and their security auditors really > going to live with that? What is the point of rolling out ECDHE so > pervasively only to undo most of the benefit? This contains a fair bit of advocacy and right now I'm just trying to get to the point where we agree on the facts. Trying to distill this into factual statements... 7. With the current design, clients have no way of knowing what, if any, anti-replay mechanisms the servers are using. Thus, they cannot be sure that servers are ensuring at-most-once semantics for the 0-RTT data (at-most-twice if the client retransmits in response to 0-RTT failure) [0]. This makes it difficult for clients to know what is safe to send in 0-RTT. 8. The more broadly distributed the information required to process a session ticket (on the server), the worse the FS situation is, with session tickets encrypted under long-lived keys being the worst. I note that you suggest separating out 0-RTT tickets and resumption tickets, but I don't actually see how that changes matters. As Ilari notes, it is possible to say that a ticket cannot be used for 0-RTT and if you have a ticket which can be used for resumption globally but for 0-RTT at just one site, the server can implement that policy unilaterally. In any case, if you think there's some other fact I've failed to capture here, I'd appreciate it if you'd add it. Thanks, -Ekr [0] Note that scoping resumption down to a given data center does not help here for removing the DKG attack. Assume that a ticket issued at data center A is good for both resumption and 0-RTT at A but cannot be used at all at B. The attacker can still transmit the CH to both A and B, and have it accepted in 0-RTT at A and a full handshake at B, at which point the client retransmits. --001a11490b9a64c26a055100cc4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
>=C2=A0
> On Thu, Jun 1, 2017 at 5:22= PM, Eric Rescorla <ekr@rtfm.com>= wrote:
>=C2=A0
> > 1. As long as 0-RTT is dec= linable (i.e., 0-RTT does not cause
> > =C2=A0 =C2=A0connec= tion failures) then a DKG-style attack where the client
> >= =C2=A0 =C2=A0replays the 0-RTT data in 1-RTT is possible.
> &= gt;
>=C2=A0
> This isn't what I call a replay= . It's a second request, but the client is
> control of it= . That distinction matters because the client can modify it if
&g= t; it needs to be unique in some way and that turns out to be important for=
> some cases.

Sure. For the sake of = clarify, I'm going to suggest we call:

- repla= y =3D=3D the attacker re-sends the data with no interaction
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with the client
- retransm= ission =3D=3D the client re-sends (possibly with some slight
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 changes)=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0=C2=A0
=C2=A0=C2=A0
> > 4. If implemented p= roperly, both a single-use ticket and a
> > =C2=A0 =C2=A0st= rike-register style mechanism make it possible to limit
> >= =C2=A0 =C2=A0the number of 0-RTT copies which are processed to 1 within
> > =C2=A0 =C2=A0a given zone (where a zone is defined as hav= ing consistent
> > =C2=A0 =C2=A0storage), so the number of = accepted copies of the 0-RTT
> > =C2=A0 =C2=A0data is N whe= re N is the number of zones.
> >
>=C2=A0
=
> This is much better than the total anarchy of allowing completely= unlimited
> replay, and it does reduce the risk for side-chan= nels, throttles etc, but I
> wouldn't consider it a proper= implementation or secure.

I'm not presently t= aking a position on whether this is secure
or proper, or whatever= . I'm just attempting to state the facts
about how the system= behaves. From this, I'm going to take
that you agree with th= is statement.=C2=A0



=
>=C2=A0
> Maybe a lot of this dilemma could = be avoided if the the PSKs that can be
> used for regular resu= mption and for 0-RTT encryption were separate, with
> the latt= er being scoped smaller and with use-at-most-once semantics.
>= =C2=A0
> 5. Implementing the level of coherency to get #4 is a= pain.
> >
> > 6. If you bind each ticket t= o a given zone, then you can
> > =C2=A0 =C2=A0get limit the= number of accepted 0-RTT copies to 1
> > =C2=A0 =C2=A0(for= that zone) and accepted 1-RTT copies to 1 (because
> > =C2= =A0 =C2=A0of the DKG attack listed above).
> >
&g= t;=C2=A0
> Yep! Agreed :)

Moving the = text above to here:


> Importantl= y it gets
> us back to a state where clients may have no contr= ol over a deterministic
> outcome.
>=C2=A0
<= div>> Some clients need idempotency tokens that are consistent for dupli= cate
> requests, this approach works ok then. Other kinds of c= lients also need
> tokens that are unique to each request atte= mpt, this approach doesn't work
> ok in that case. That= 9;s the qualitative difference.
>=C2=A0
> I'd= also add that the suggested optimization here is clearly to support
<= div>> globally resumable session tickets that are not scoped to a single= site.
> That's a worthy goal; but it's unfortunate th= at in the draft design it also
> means that 0-RTT sections wou= ld be globally scoped. That's seems bad to me
> because it= 's so hostile to forward secrecy, and hostile to protecting the
> most critical user-data. What's the point of having FS for ever= ything
> except the requests, where the auth details often are= , and which can
> usually be used to generate the response? Sy= nchronizing keys that can
> de-cloak an arbitrary number of su= ch sessions to many data centers spread
> out across the world= , seems just so defeating. I realize that it's common
> to= day, I've built such systems, but at some point we have to decide that = FS
> either matters or it doesn't. Are users and their sec= urity auditors really
> going to live with that? What is the p= oint of rolling out ECDHE so
> pervasively only to undo most o= f the benefit?

This contains a fair bit of advocac= y and right now I'm just trying to
get to the point where we = agree on the facts. Trying to distill this into
factual statement= s...


7. With the current design, cl= ients have no way of knowing what, if any,
=C2=A0 =C2=A0anti-repl= ay mechanisms the servers are using. Thus, they cannot be
=C2=A0 = =C2=A0sure that servers are ensuring at-most-once semantics for the 0-RTT
=C2=A0 =C2=A0data (at-most-twice if the client retransmits in resp= onse to 0-RTT
=C2=A0 =C2=A0failure) [0]. This makes it difficult = for clients to know what is
=C2=A0 =C2=A0safe to send in 0-RTT.

8. The more broadly distributed the information req= uired to process
=C2=A0 =C2=A0a session ticket (on the server), t= he worse the FS situation is,
=C2=A0 =C2=A0with session tickets e= ncrypted under long-lived keys being the
=C2=A0 =C2=A0worst.

I note that you suggest separating out 0-RTT tickets a= nd resumption
tickets, but I don't actually see how that chan= ges matters. As Ilari
notes, it is possible to say that a ticket = cannot be used for 0-RTT
and if you have a ticket which can be us= ed for resumption globally
but for 0-RTT at just one site, the se= rver can implement that policy
unilaterally.

=
In any case, if you think there's some other fact I've failed = to
capture here, I'd appreciate it if you'd add it.
=

Thanks,
-Ekr


[0] Note that scoping resumption down to a given data center does n= ot
help here for removing the DKG attack. Assume that a ticket is= sued at
data center A is good for both resumption and 0-RTT at A = but cannot be
used at all at B. The attacker can still transmit t= he CH to both A and
B, and have it accepted in 0-RTT at A and a f= ull handshake at B, at
which point the client retransmits.
<= div>
--001a11490b9a64c26a055100cc4b-- From nobody Fri Jun 2 14:39:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F84127241 for ; Fri, 2 Jun 2017 14:39:45 -0700 (PDT) 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, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-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=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 iX8pkQgD35b0 for ; Fri, 2 Jun 2017 14:39:43 -0700 (PDT) Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d: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 DAC75126D73 for ; Fri, 2 Jun 2017 14:39:42 -0700 (PDT) Received: by mail-qk0-x229.google.com with SMTP id d14so69368502qkb.1 for ; Fri, 02 Jun 2017 14:39:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Bnr7BFW0WVzbZeeVB56/jGGchKM+52e2HelUvo5Tqw0=; b=b1y6Ctbya8gRh0BpWJSg+xOZBo6IrVn3Oi12iXJcCqdHZIviQ7lEkvaSNoc4u1TVdz +aGMLJU1/MObg0Vt/mHJ6nVpGIPXr5OI7aIT0jBKnh0xRTGDhlsu14NUkZBWi2JX8nmL cknjWMZ4TkP4/o7XPKR3pEpjsXgwl4BAKP0GNHuENPnjp8olNnbCRDsm2v+sVo+uCB3O xFiqvtRjycZjHsvSQWTcekti4VZ3NlwhPBi95oMJY1193KFl7zu3FgamPXksZXaa8uK3 OB7NbeuIhWWeIcQWYdWLHmQA6VJDWB7H/PhmZBDxn8cWD2J5t3SMkRgXV4c0nR8IPj6+ RMJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Bnr7BFW0WVzbZeeVB56/jGGchKM+52e2HelUvo5Tqw0=; b=PSiJyumZbx//KsvEZVwXwXBbOR51DxEfJtZ1GX17btVtxUYVL7Ld9wrhiLGKhZVrw7 o6CXjERp54AHEikE1yUDmBrz/j3EfZtZvRFahpA7ISIYFb2s2q6iOeSB0ZaeEwCR8feR iGwOwO27dfG4IER/7U96pQv5awQKvlwx1KmS1s7zpxxR30S+6LJE/FphTwzB1spL5vxc JlalM+PcgDJ/UCibZ0SBjYsNhbllnW4nJUSRjEemShn8SbQ8SY5DLWE02YVbhgIHuRZu c3u0d9RI4LpxSiTEeFigD9pyp2UATDG09Jygt8+W09WRKgipdseDCYd7+kPOS+rTXpQ/ TmNA== X-Gm-Message-State: AKS2vOzL5jx0T47sxymhjr/w8NHKe94v9/HHj1z0ZMOZNPw/scYPKGlE /rhxjhaSB7Tfvu2JvXzlwviiFyrBjOUwkXY= X-Received: by 10.55.45.198 with SMTP id t189mr10850393qkh.108.1496439581720; Fri, 02 Jun 2017 14:39:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.65 with HTTP; Fri, 2 Jun 2017 14:39:40 -0700 (PDT) In-Reply-To: References: From: Victor Vasiliev Date: Fri, 2 Jun 2017 17:39:40 -0400 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114f50b0b2ac20055100fdb0" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 21:39:45 -0000 --001a114f50b0b2ac20055100fdb0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 1, 2017 at 7:59 PM, Colm MacC=C3=A1rthaigh = wrote: > On Thu, Jun 1, 2017 at 1:50 PM, Victor Vasiliev > wrote: > >> I am not sure I agree with this distinction. I can accept the differenc= e >> in >> terms of how much attacker can retry -- but we've already agreed that >> bounding >> that number is a good idea. I don't see any meaningful distinction in >> other >> regards. >> > > It's not just a difference in the number of duplicates. With retries, the > client maintains some control, so it can do things like impose delays and > update request IDs. Bill followed up with an exactly relevant example fro= m > Token Binding where the retry intentionally has a different token value. > That kind of control is lost with attacker driven replays. > I am not sure I understand the context in which this is relevant. I cannot imagine anyone delay the 1-RTT fallback, given that 0-RTT is expected to fail regularly. I also don't understand how changing request ID would help -- I would assume that for retry safety, you'd actually want the ID to be the same across all attempts. Could you give me a scenario where this actually changes the security properties of the system? (I understand the tokbind case -- but tokbind 0-RTT has different operational requirements from plain TLS; those are documented in draft-ietf-tokbind-tls13-0rtt and are somewhat out of scope for this conversation) > But even if we focus on just the number; there is something special about > allowing 0 literal replays of a 0-RTT section; it is easy for users to > confirm/audit/test. If there's a hard-guaranteee that 0-RTT "MUST" never = be > replayable, then I feel like we have a hope of producing a viable 0-RTT > ecosystem. Plenty of providers may screw this up, or try to cut corners, > but if we can ensure that they get failing grades in security testing > tools, or maybe even browser warnings, then we can corral things into a > zone of safety. Otherwise, with no such mechanism, I fear that bad > operators will cause the entire 0-RTT feature to be tainted and entirely > turned off over time by clients. > You can't really audit this property, since you never have a comprehensive list of endpoints to which a 0-RTT can be replayed. > >> Sure, but this is just an argument for making N small. Also, retrys can >> also >> be directed to arbitrary nodes. >> > > This is absolutely true, but see my point about the client control. > Regardless, it is a much more difficult attack to carry out. That is to > intercept and rewrite a whole TCP connection Vs grabbing a 0-RTT section > and sending it again. > It's within the scope of the threat model. > Well in the real world, I think it'll be pervasive, and I even think it >>> /should/ be. We should make 0-RTT that safe and remove the sharp edges. >>> >> >> Are you arguing that non-safe requests should be allowed to be sent via >> 0-RTT? >> Because that actually violates reasonable expectations of security >> guarantees >> for TLS, and I do not believe that is acceptable. >> > > I'm just saying that it absolutely will happen, and I don't think any kin= d > of lawyering about the HTTP spec and REST will change that. Folks use GET= s > for non-idempotent side-effect-bearing APIs a lot. And those folks don't > generally understand TLS or have anything to do with it. I see no real > chance of that changing and it's a bit of a deceit for us to think that > it's realistic that there will be these super careful 0-RTT deployments > where everyone from the Webserver administrator to the high-level > application designer is coordinating and fully aware of all of the > implications. It crosses layers that are traditionally quite far apart. > > So with that in mind, I argue that we have to make TLS transport as secur= e > as possible by default, while still delivering 0-RTT because that's such = a > beneficial improvement. > Well, 0-RTT is inherently unsafe in a sense that it could be retried at least one time. This means that we have to draw a line somewhere. Safe requests seem like a fine line to draw, in a sense that the ecosystem is already free to try and retry GET requests at will (if you don't retry yourself, your HTTP proxy might). If you believe we should use a more conservative approach, I am happy to hear your suggestions. > > >> I do not believe that this to be the case. The DKG attack is an attack >>>> that allows >>>> for a replay. >>>> >>> >>> It's not. It permits a retry. The difference here is that the client is >>> in full control. It can decide to delay, to change a unique request ID,= or >>> even not to retry at all. But the legitimate client generated the first >>> attempt, it can be signaled that it wasn't accepted, and then it genera= tes >>> the second attempt. If it really really needs to it can even reason abo= ut >>> the complicated semantics of the earlier request being possibly >>> re-submitted later by an attacker. >>> >> >> That's already not acceptable for a lot of applications -- and by enabli= ng >> 0-RTT for non-safe HTTP requests, we would be pulling the rug from under >> them. >> > > Yep; but I think /this/ risk is manageable and tolerable. Careful clients= , > like the token binding case, can actually mitigate this. I've outlined th= e > scheme. For careless clients, like browsers, they can mostly ignore this; > since they retry so easily anyway, it's no worse. > The problem is not just that it's a retry, but it also can be done out-of-order. Imagine I have a configuration system, and my client can take out a global lock for some operation, and normally an update to it looks like this: 1. GET to check if the current state needs updating. 2. POST to take a lock. 3. GET to check if current state still holds. 4. POST to update the data held by the lock. 5. POST to release the lock and publish the notification. 6. GET to ensure the lock was released. Now, imagine the following attack: a) Between (1) and (2), the attacker resets the TCP connection, after the client got the response and the session ticket. b) Since the client has the ticket, it 0-RTTs the POST to take out a lock. c) Attacker redirects the client to another datacenter, which cannot accept 0-RTT, so it switches to 1-RTT. d) During (b) and (c), the attacker records a transcript of 0-RTT request to take out a lock. d) The rest of (2)-(6) proceed in normal fashion via client talking to the distant datacenter. e) Attacker replays the lock being taken out in the datacenter where 0-RTT would succeed; the lock now is in place, and the client has no idea about it. Because the application layer cannot reasonably assume that such reordering can happen, it is not acceptable to 0-RTT the POST in #2. > But there is *no* proposed mitigation for replayable 0-RTT. So I don't > think that's manageable. Just trying to make a data-driven decision. If > someone presents an alternative mitigation (besides forbidding replays), > I'll change my mind. > The proposed mitigation is the application-layer profile prohibiting unsafe requests via 0-RTT. > > >> Throttling POST requests is fine -- they shouldn't go over 0-RTT, since >> they >> are not idempotent. Throttling GET requests in this manner goes at odds >> with >> RFC 7231. >> > > Throttling GET requests happens all of the time and is an important > security and fairness measure used by many deployed systems. 0-RTT would > break it. That's not ok. > > I don't think it is at odds with RFC 7231 ... which also defines the 503 > status code. > As I said, the N may vary and can be set by the service operator depending on what kind of infrastructure they run. It might be much easier for a service to increase its throttling thresholds 10x and set N=3D10, than to set N=3D1. -- Victor. --001a114f50b0b2ac20055100fdb0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 1, 2017 at 7:59 PM, Colm MacC=C3=A1rthaigh <colm@allcosts.net&= gt; wrote:
On= Thu, Jun 1, 2017 at 1:50 PM, Victor Vasiliev <vasilvv@google.com>= wrote:
I am n= ot sure I agree with this distinction.=C2=A0 I can accept the difference in=
terms of how much attacker can retry -- but we've already ag= reed that bounding
that number is a good idea.=C2=A0 I don't = see any meaningful distinction in other
regards.=C2=A0
<= /div>

It's not just = a difference in the number of duplicates. With retries, the client maintain= s some control, so it can do things like impose delays and update request I= Ds. Bill followed up with an exactly relevant example from Token Binding wh= ere the retry intentionally has a different token value. That kind of contr= ol is lost with attacker driven replays.=C2=A0

I am not sure I understand the context in = which this is relevant. =C2=A0I
cannot imagine anyone delay the 1= -RTT fallback, given that 0-RTT is
expected to fail regularly.=C2= =A0 I also don't understand how changing
request ID would hel= p -- I would assume that for retry safety, you'd
actually wan= t the ID to be the same across all attempts.=C2=A0 Could you give
me a scenario where this actually changes the security properties of the
system?

(I understand the tokbind case --= but tokbind 0-RTT has different
operational requirements from pl= ain TLS; those are documented in
draft-ietf-tokbind-tls13-0rtt an= d are somewhat out of scope for this
conversation)
=C2=A0
But ev= en if we focus on just the number; there is something special about allowin= g 0 literal replays of a 0-RTT section; it is easy for users to confirm/aud= it/test. If there's a hard-guaranteee that 0-RTT "MUST" never= be replayable, then I feel like we have a hope of producing a viable 0-RTT= ecosystem. Plenty of providers may screw this up, or try to cut corners, b= ut if we can ensure that they get failing grades in security testing tools,= or maybe even browser warnings, then we can corral things into a zone of s= afety. Otherwise, with no such mechanism, I fear that bad operators will ca= use the entire 0-RTT feature to be tainted and entirely turned off over tim= e by clients.=C2=A0

You can't really audit this property, since you never have a
comprehensive list of endpoints to which a 0-RTT can be replayed.
=C2=A0
=

Sure, but this is just an argument for making N small.=C2=A0 Also, re= trys can also
be directed to arbitrary nodes.=C2=A0

This is absolutely tr= ue, but see my point about the client control. Regardless, it is a much mor= e difficult attack to carry out. That is to intercept and rewrite a whole T= CP connection Vs grabbing a 0-RTT section and sending it again.

It's within the scope of = the threat model.

=C2=A0
Well in the= real world, I think it'll be pervasive, and I even think it /should/ b= e. We should make 0-RTT that safe and remove the sharp edges.=C2=A0

Are you arguing tha= t non-safe requests should be allowed to be sent via 0-RTT?
Becau= se that actually violates reasonable expectations of security guarantees
for TLS, and I do not believe that is acceptable.

I'm just saying that = it absolutely will happen, and I don't think any kind of lawyering abou= t the HTTP spec and REST will change that. Folks use GETs for non-idempoten= t side-effect-bearing APIs a lot. And those folks don't generally under= stand TLS or have anything to do with it. I see no real chance of that chan= ging and it's a bit of a deceit for us to think that it's realistic= that there will be these super careful 0-RTT deployments where everyone fr= om the Webserver administrator to the high-level application designer is co= ordinating and fully aware of all of the implications. It crosses layers th= at are traditionally quite far apart.=C2=A0

So wit= h that in mind, I argue that we have to make TLS transport as secure as pos= sible by default, while still delivering 0-RTT because that's such a be= neficial improvement.=C2=A0

Well, 0-RTT is inherently unsafe in a sense that it could be retri= ed
at least one time.=C2=A0 This means that we have to draw a lin= e somewhere.
Safe requests seem like a fine line to draw, in a se= nse that the
ecosystem is already free to try and retry GET reque= sts at will (if you
don't retry yourself, your HTTP proxy mig= ht).=C2=A0 If you believe we should
use a more conservative appro= ach, I am happy to hear your suggestions.
=C2=A0
=C2=A0
I = do not believe that this to be the case.=C2=A0 The DKG attack is an attack = that allows
for a replay.=C2=A0

It's not. It permits a retry. The d= ifference here is that the client is in full control. It can decide to dela= y, to change a unique request ID, or even not to retry at all. But the legi= timate client generated the first attempt, it can be signaled that it wasn&= #39;t accepted, and then it generates the second attempt. If it really real= ly needs to it can even reason about the complicated semantics of the earli= er request being possibly re-submitted later by an attacker.=C2=A0

That's alre= ady not acceptable for a lot of applications -- and by enabling
0= -RTT for non-safe HTTP requests, we would be pulling the rug from under the= m.

Yep= ; but I think /this/ risk is manageable and tolerable. Careful clients, lik= e the token binding case, can actually mitigate this. I've outlined the= scheme. For careless clients, like browsers, they can mostly ignore this; = since they retry so easily anyway, it's no worse.=C2=A0

The problem is not just that = it's a retry, but it also can be done
out-of-order.

Imagine I have a configuration system, and my client can ta= ke out a
global lock for some operation, and normally an update t= o it looks like
this:

=C2=A0 1. GET to c= heck if the current state needs updating.
=C2=A0 2. POST to take = a lock.
=C2=A0 3. GET to check if current state still holds.
=C2=A0 4. POST to update the data held by the lock.
=C2=A0 = 5. POST to release the lock and publish the notification.
=C2=A0 = 6. GET to ensure the lock was released.

Now, imagi= ne the following attack:

=C2=A0 a) Between (1) and= (2), the attacker resets the TCP connection, after
=C2=A0 =C2=A0= =C2=A0the client got the response and the session ticket.
=C2=A0= b) Since the client has the ticket, it 0-RTTs the POST to take out a
=
=C2=A0 =C2=A0 =C2=A0lock.
=C2=A0 c) Attacker redirects the c= lient to another datacenter, which cannot
=C2=A0 =C2=A0 =C2=A0acc= ept 0-RTT, so it switches to 1-RTT.
=C2=A0 d) During (b) and (c),= the attacker records a transcript of 0-RTT
=C2=A0 =C2=A0 =C2=A0r= equest to take out a lock.
=C2=A0 d) The rest of (2)-(6) proceed = in normal fashion via client talking to
=C2=A0 =C2=A0 =C2=A0the d= istant datacenter.
=C2=A0 e) Attacker replays the lock being take= n out in the datacenter where
=C2=A0 =C2=A0 =C2=A00-RTT would suc= ceed; the lock now is in place, and the client has
=C2=A0 =C2=A0 = =C2=A0no idea about it.

Because the application la= yer cannot reasonably assume that such
reordering can happen, it = is not acceptable to 0-RTT the POST in #2.

= =C2=A0
But there is= *no* proposed mitigation for replayable 0-RTT. So I don't think that&#= 39;s manageable. Just trying to make a data-driven decision. If someone pre= sents an alternative mitigation (besides forbidding replays), I'll chan= ge my mind.=C2=A0

The proposed mitigation is the application-layer profile prohibiting
unsafe requests via 0-RTT.
=C2=A0
=C2=A0
Throttling POST requests is fine -- they s= houldn't go over 0-RTT, since they
are not idempotent.=C2=A0 = Throttling GET requests in this manner goes at odds with
R= FC 7231.

Thro= ttling GET requests happens all of the time and is an important security an= d fairness measure used by many deployed systems. 0-RTT would break it. Tha= t's not ok.=C2=A0

I don't think it is at o= dds with RFC 7231 ... which also defines the 503 status code.=C2=A0

As I said, the N may = vary and can be set by the service operator
depending on what kin= d of infrastructure they run.=C2=A0 It might be much
easier for a= service to increase its throttling thresholds 10x and set
N=3D10= , than to set N=3D1.

=C2=A0 -- Victor.
=
--001a114f50b0b2ac20055100fdb0-- From nobody Fri Jun 2 14:49:56 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C693126D73 for ; Fri, 2 Jun 2017 14:49:55 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-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=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 u9xp9B9sLrCl for ; Fri, 2 Jun 2017 14:49:53 -0700 (PDT) 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 6CEA312422F for ; Fri, 2 Jun 2017 14:49:53 -0700 (PDT) Received: by mail-qk0-x22e.google.com with SMTP id d14so69504462qkb.1 for ; Fri, 02 Jun 2017 14:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M2t4YlYiIk2Vqkl1bLq8j+IgvqH2vsv4nwSYZKhnJz8=; b=fb/YMjgtFkktsXJeeyBhpI8Ri5TpKL+dPUTtlc/jLzO8IxTkXGPG3PJowpiPiYF+Vc ZCn4B6A+uQpqm5N1RvjZnyeqhb5EAjjvRaQ/FJCjjGzziCLtFLTMd0BSWgnSDwO2/UQv 4SIc8fwJ2rk3g4w//i91P7EPiGNaea31Uh5z3A+ZKvfyAwZCH5w89bwRNwPVnW+6wauz 1Xv+dw5leNp6vHYWfPl0YXyRL3ZXEuj3z/CXtZA7xZWqEujg5UQrbMQ5sRgy5RhGDem0 1RKdLNGfDz7hqUCJWsBRyzMfSS5BXk83lGvoHOqBnpv9fFE9jIXYSCAYvI5bGyNeXFwz DVWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M2t4YlYiIk2Vqkl1bLq8j+IgvqH2vsv4nwSYZKhnJz8=; b=hl/KmJkHeiAkxw6ZlXtXHM+6ZNH2/xIJIsQlBuCRP3CfHISl0+/vals8xZhYbWH08q egWlWlZVQhMrBtKWuSgqA0D+ZLH2yo0asHUg148gHcrCXsk2vzUW3ghYgDj/bJkRoeiL mf5lETSm7zzyZb6KZobT23zCuJYyWLbOPChTATwCy1X3B9+lcVop6JuXHGI6nx76Kp5j SjQPTdv8mSTsFlc66FOVsaLJbUJKQxxCN2bqYO/yQ0d965Zx55vIw8CsiSTPFIDj0C/l azBGrzMDEfxE/9gOIzf51QMOlPnZ+jUxgCA+M59VQp0awuskfQVw/95DBrNbiglttoML 9EfA== X-Gm-Message-State: AKS2vOxB2d1Ksh1C7srPcPz1tAzqTESWvxLN3Nf1mI9mLk7eeGKAwtAL Fge0DU5QmhREnaiD+efQBy1+E4uuCqJb X-Received: by 10.55.45.198 with SMTP id t189mr10894792qkh.108.1496440192435; Fri, 02 Jun 2017 14:49:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.65 with HTTP; Fri, 2 Jun 2017 14:49:51 -0700 (PDT) In-Reply-To: References: From: Victor Vasiliev Date: Fri, 2 Jun 2017 17:49:51 -0400 Message-ID: To: Eric Rescorla Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114f50b01990480551012230" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 21:49:55 -0000 --001a114f50b01990480551012230 Content-Type: text/plain; charset="UTF-8" On Thu, Jun 1, 2017 at 8:22 PM, Eric Rescorla wrote: > I've just gone through this thread and I'm having a very hard time > understanding what the actual substantive argument is about. > I believe at this point we mostly disagree on what specific scenarios are and are not a concern that should be solved by TLS layer. Replay/retry distinction might be at core for some disagreements. Let me lay out what I think we all agree on. > > 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause > connection failures) then a DKG-style attack where the client > replays the 0-RTT data in 1-RTT is possible. > Correct. > 2. Because of point #1, applications must implement some form > of replay-safe semantics. > Correct. > > 3. Allowing the attacker to generate an arbitrary number of 0-RTT > replays without client intervention is dangerous even if > the application implements replay-safe semantics. > Correct, and the specific number is highly situational. > > 4. If implemented properly, both a single-use ticket and a > strike-register style mechanism make it possible to limit > the number of 0-RTT copies which are processed to 1 within > a given zone (where a zone is defined as having consistent > storage), so the number of accepted copies of the 0-RTT > data is N where N is the number of zones. > Correct. Session caches are inherently bound to a single zone. > 5. Implementing the level of coherency to get #4 is a pain. > Yes. > 6. If you bind each ticket to a given zone, then you can > get limit the number of accepted 0-RTT copies to 1 > (for that zone) and accepted 1-RTT copies to 1 (because > of the DKG attack listed above). > > Correct. -- Victor. --001a114f50b01990480551012230 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= hu, Jun 1, 2017 at 8:22 PM, Eric Rescorla <ekr@rtfm.com> wrote:
I= 've just gone through this thread and I'm having a very hard time
understanding what the actual substantive argument is about.
=

I believe at this point we mostly di= sagree on what specific scenarios
are and are not a concern that = should be solved by TLS layer.
Replay/retry distinction might be = at core for some disagreements.=C2=A0

Let m= e lay out what I think we all agree on.

1. As long= as 0-RTT is declinable (i.e., 0-RTT does not cause
=C2=A0 =C2=A0= connection failures) then a DKG-style attack where the client
=C2= =A0 =C2=A0replays the 0-RTT data in 1-RTT is possible.

Correct.
=C2=A0
2. Because of point #1,= applications must implement some form
=C2=A0 =C2=A0of replay-saf= e semantics.

Correct.
=C2=A0

3. Allowing the attacker to generate an arbitrary = number of 0-RTT
=C2=A0 =C2=A0replays without client intervention = is dangerous even if
=C2=A0 =C2=A0the application implements repl= ay-safe semantics.

Correct, and= the specific number is highly situational.
=C2=A0
=C2=A0 =C2= =A0
4. If implemented properly, both a single-use ticket and a
=C2=A0 =C2=A0strike-register style mechanism make it possible to li= mit
=C2=A0 =C2=A0the number of 0-RTT copies which are processed t= o 1 within
=C2=A0 =C2=A0a given zone (where a zone is defined as = having consistent
=C2=A0 =C2=A0storage), so the number of accepte= d copies of the 0-RTT
=C2=A0 =C2=A0data is N where N is the numbe= r of zones.

Correct.=C2=A0 Sess= ion caches are inherently bound to a single zone.
=C2=A0
5. Imp= lementing the level of coherency to get #4 is a pain.

Yes.
=C2=A0
6. If you bind each ticket t= o a given zone, then you can
=C2=A0 =C2=A0get limit the number of= accepted 0-RTT copies to 1
=C2=A0 =C2=A0(for that zone) and acce= pted 1-RTT copies to 1 (because
=C2=A0 =C2=A0of the DKG attack li= sted above).


Cor= rect.

=C2=A0 -- Victor.
--001a114f50b01990480551012230-- From nobody Fri Jun 2 15:34:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17692129422 for ; Fri, 2 Jun 2017 15:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 zInTU52f__OI for ; Fri, 2 Jun 2017 15:33:57 -0700 (PDT) Received: from resqmta-po-10v.sys.comcast.net (resqmta-po-10v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:169]) (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 06A56126B7E for ; Fri, 2 Jun 2017 15:33:56 -0700 (PDT) Received: from resomta-po-06v.sys.comcast.net ([96.114.154.230]) by resqmta-po-10v.sys.comcast.net with SMTP id Gv87d70CSiWLuGv8ldHpvF; Fri, 02 Jun 2017 22:33:55 +0000 Received: from [IPv6:::1] ([73.222.32.57]) by resomta-po-06v.sys.comcast.net with SMTP id Gv8cdK0CFufs1Gv8jd6gtS; Fri, 02 Jun 2017 22:33:55 +0000 To: "tls@ietf.org" From: Andrey Jivsov Message-ID: Date: Fri, 2 Jun 2017 15:33:46 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-CMAE-Envelope: MS4wfLTKRUMogtWFM2XS6Z2Yi24RR+1m1Oo40SWvHfUI/Gv+m/1mOUxixoGvjGCPc+W9ew6/5sd4QcRKyxyMBWF5j2J36IXZzTkjIeiEOTrBBcc7ByfbH0oK jcXyejc/nMfhQQlzU3134qnKf2UYL0NYtwdkVIYk4twRxADDlZKrSTuS Archived-At: Subject: [TLS] Improved nonce generation method for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 22:33:59 -0000 Greetings. I would like to suggest a small tweak to the nonce generation method in TLS 1.3. The motivation for this is stronger separation between the encryption layer and the TLS layer. An alignment with FIPS 140 guidance is another motivation, which tells that the IV management shall be internal (in encryption direction). I realize that what I propose is a small tweak, and consequently, it provides small benefits. One can take any side here. My view is that we should try to clean things up, when possible. Instead of requiring the understanding of the record numbers, the encryption layer simply increments the initial nonce, which is a 12-byte quantity for AES-GCM. The TLS layer passes in client_write_iv or server_write_iv, along with the key, once per session, and the encryption layer does ++ on nonce for each record from that point. The method can be described as a counter mode with a random start. There is one caveat. In order to maintain protocol version independence we want to inhibit carry into the higher bytes (4 high bytes for AES-GCM). This is behavior is standardized by https://tools.ietf.org/html/rfc5116 and applies to TLS 1.2. The benefits are that the encryption layer doesn't need to deal with a record number or its serialization, or the mask. The state is minimal. The nonce update code is faster and smaller (e.g. 3 instructions on x86_64). I would like to thank earlier reviewers. As part of these reviews RFC7905 was brought up. I appreciate the desire not to update the RFC7905, but this should not interfere with the WGLC, and it's a fairly new stream cipher anyway. Details are in https://github.com/tlswg/tls13-spec/pull/1027 Thank you. From nobody Fri Jun 2 16:21:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE007128DF6 for ; Fri, 2 Jun 2017 16:21:01 -0700 (PDT) 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 Ug2NHeRIi0L2 for ; Fri, 2 Jun 2017 16:20:59 -0700 (PDT) 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 C8CA0128B8F for ; Fri, 2 Jun 2017 16:20:59 -0700 (PDT) Received: by mail-it0-x234.google.com with SMTP id r63so33433670itc.1 for ; Fri, 02 Jun 2017 16:20:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=8juIlAzwYrk3EocENgk59e1bcRe4ebSjQbbkbHNgeio=; b=u83tACUC1Yf0gpWqyFNJ4TDTa1Qy2b5z6ynhzHABzrAHxUo/aUALdV9OpwGOqCUqgj ryrGKv/YSFHsoEgG9njfSUsVy/I6AY4QFuujZ5A3hGXBkkFbnmX33QcX7mAmiivCAih6 PwJuVtmPbGLrnNVHzoRJYxItaUnpT7E1DrYb03tTPdprM3lF75pqj9eczt+0i7FwdjDt hV7Eq/Mjipuei4QSXY0BlK7rnw2RIXqnXI5Gjt+3HjoplpQJ2PQeu44SQD+3e7q3bMbK zkSF3HCh3rhmtDT1N7C7gUOG37KUk8oR89Wb9PuYg0ObqnciB0gemeSTLx4HAPhMRGPG y/HQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=8juIlAzwYrk3EocENgk59e1bcRe4ebSjQbbkbHNgeio=; b=s5RsdcyZie1Y/I9qVBUKe0FQfmISoNJ0mgztZSdPKBTNreDUyK70hG+pbXmtbPSrsu /uuOHA26e+i+DIruTWm8dpjx/pbHS94ACIJrs50NoOm1zxKoDS03I29/MpoyTkl8Qptr 9cgnr+y6QBVhSYm2NHfJ1jAd8GfP5j8YYLur1XFvD5hyZ373HJDx0na1ypZcyXMa66z4 1lZynLHaq8IbosRmmkU9zUx7wGV62R15V6mcy7r2Im8WBbuinxK+3DH5UUTZFXnSo762 ClH/UaT+wmwKXaNhyjh4lL3w9rpGADxa2+fm6wUohEBQVTesmWP1W/nDrjicIXeSxxbB zvuA== X-Gm-Message-State: AODbwcArAJ5csxKrSdO/PSNCf9S9Qnhsr08eHQhb+8bW1G/qDw6MX4OE za+kk3lDEzrrVBZYHfYlOfF7rTLvyw== X-Received: by 10.36.29.81 with SMTP id 78mr1896378itj.33.1496445659136; Fri, 02 Jun 2017 16:20:59 -0700 (PDT) MIME-Version: 1.0 Sender: alangley@gmail.com Received: by 10.79.42.135 with HTTP; Fri, 2 Jun 2017 16:20:58 -0700 (PDT) In-Reply-To: References: From: Adam Langley Date: Fri, 2 Jun 2017 16:20:58 -0700 X-Google-Sender-Auth: 8f3hvvvwV9hgvp1KVuyL9Edptxk Message-ID: To: Andrey Jivsov Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1143e172f04ab4055102674d" Archived-At: Subject: Re: [TLS] Improved nonce generation method for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 23:21:02 -0000 --001a1143e172f04ab4055102674d Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov wrote: > The benefits are that the encryption layer doesn't need to deal with a > record number or its serialization, or the mask. The state is minimal. > The nonce update code is faster and smaller (e.g. 3 instructions on > x86_64). > > I would like to thank earlier reviewers. As part of these reviews > RFC7905 was brought up. I appreciate the desire not to update the > RFC7905, but this should not interfere with the WGLC, and it's a fairly > new stream cipher anyway. > If the encryption layer implements the standard interface[1] then it doesn't care about any of this anyway. Also, I'm not sure that it is any faster (the current scheme can be done in three x86-64 instructions too[2]), but any difference would be immeasurably tiny compared to the work of the AEAD itself. The overriding interest here is to avoid having yet another nonce format. RFC 7905 diverged from TLS 1.2 with the intent that it would align with TLS 1.3. There would have to be a significant reason to add more complexity. [1] https://tools.ietf.org/html/rfc5116#section-2.1 [2] context struct addr in rax, seq number in rcx: leaq maskOffset(%rax), %rbx ; xorq (%rbx), %rcx ; movbeq %rcx, 4(%rdi) Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org --001a1143e172f04ab4055102674d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov <crypto@brainhub.org> wrote:
The benef= its are that the encryption layer doesn't need to deal with a
record number or its serialization, or the mask. The state is minimal.
The nonce update code is faster and smaller (e.g. 3 instructions on x86_64)= .

I would like to thank earlier reviewers. As part of these reviews
RFC7905 was brought up. I appreciate the desire not to update the
RFC7905, but this should not interfere with the WGLC, and it's a fairly=
new stream cipher anyway.

If the encryp= tion layer implements the standard interface[1] then it doesn't care ab= out any of this anyway. Also, I'm not sure that it is any faster (the c= urrent scheme can be done in three x86-64 instructions too[2]), but any dif= ference would be immeasurably tiny compared to the work of the AEAD itself.=

The overriding interest here is to avoid having y= et another nonce format. RFC 7905 diverged from TLS 1.2 with the intent tha= t it would align with TLS 1.3. There would have to be a significant reason = to add more complexity.

[2] context struct addr in rax, seq number in rcx:= leaq maskOffset(%rax), %rbx ; xorq (%rbx), %rcx ; movbeq %rcx, 4(%rdi)


Cheers

AGL

--
Adam Langley agl@imperialviolet.org= https://www.i= mperialviolet.org
--001a1143e172f04ab4055102674d-- From nobody Fri Jun 2 16:26:12 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F39F129415 for ; Fri, 2 Jun 2017 16:26:11 -0700 (PDT) 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 qjVQnhsJm9MJ for ; Fri, 2 Jun 2017 16:26:10 -0700 (PDT) Received: from mail-yb0-x230.google.com (mail-yb0-x230.google.com [IPv6:2607:f8b0:4002: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 C94A1128B8F for ; Fri, 2 Jun 2017 16:26:09 -0700 (PDT) Received: by mail-yb0-x230.google.com with SMTP id o9so5312099yba.3 for ; Fri, 02 Jun 2017 16:26:09 -0700 (PDT) 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=URDBkh9fjwaNSOyeoMFDF+JJQQMpp9wUaWuFqpA4Zig=; b=2T9p4GWu9NOYhi+G+JatU7g3kd/qUrcfm1itbyNIQaygUhwTQHT9wzbEQjIwHR4a/d 9Qqtg65kx3+IAy/jJglqBsEFE9WCNK78aTT68kepdzmlXgbZrp01a2RTeYHNoUUmdG3I d73cTacvqWb8V9Sfqk1LXE9RC08uPOO+TUgdCp6L+56CANGh1Qq9JChjAMnKLaK93Erd 25Qpth4hz2HggKh50FQLDcCAKnNlTPIGhjJ8qbbjLCshTcJhAGOI533ouOTmUdqaDISm IuQ/0Cz+uaK3vWqgMV8BBZs0It8YYBsTrjLRCd8ymNCUn8gjVykgZib+qLI/AinJ1xeo rv3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=URDBkh9fjwaNSOyeoMFDF+JJQQMpp9wUaWuFqpA4Zig=; b=rtfoxwDkjk5+Expc2F9Cf9w84k1DUddbbELZBqFyvfsT3Bt5g3BkomGk3YDT+srwR3 U1WAjMrzQNS+MK8fNlylxoOdCk6CaIlmPFjFyuET42uKSdDgfo48Lqan/Ttu3hxAMpV9 wjYubEyhH9dXwVzSeubl3vyKj8j1OGj+RhEKEG+hF0sJ9l7q+/x1SAvO0AbcPhOrIVdg CKOqwfwMf9/EjbX4VxDKTSHX77qXq48yGlSoVJNyxxY5X6lwfOnyvCeGHnetYVeqqPeh 58kCMQMl5fW0zACEgM65VGnjVLAWCr5x9RREd8TD18SOYw9KsQdPJdcmIn2UZTyY8hKL YxxA== X-Gm-Message-State: AODbwcDxYJiUa/JW0NG/6NbndC4MHp+o1n5BSw6ckdTDlU0FJfChj0/P KmT3+hzu1cIuMM1tLOpY735xpl/QqV/KGG4= X-Received: by 10.37.162.100 with SMTP id b91mr1886051ybi.29.1496445969041; Fri, 02 Jun 2017 16:26:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.4 with HTTP; Fri, 2 Jun 2017 16:25:28 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Fri, 2 Jun 2017 16:25:28 -0700 Message-ID: To: Adam Langley Cc: Andrey Jivsov , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19f3b46921690551027aa5" Archived-At: Subject: Re: [TLS] Improved nonce generation method for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 23:26:11 -0000 --94eb2c19f3b46921690551027aa5 Content-Type: text/plain; charset="UTF-8" It's worth noting that we considered a variant of this design initially and then decided on the XOR design instead. -Ekr On Fri, Jun 2, 2017 at 4:20 PM, Adam Langley wrote: > On Fri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov wrote: > >> The benefits are that the encryption layer doesn't need to deal with a >> record number or its serialization, or the mask. The state is minimal. >> The nonce update code is faster and smaller (e.g. 3 instructions on >> x86_64). >> >> I would like to thank earlier reviewers. As part of these reviews >> RFC7905 was brought up. I appreciate the desire not to update the >> RFC7905, but this should not interfere with the WGLC, and it's a fairly >> new stream cipher anyway. >> > > If the encryption layer implements the standard interface[1] then it > doesn't care about any of this anyway. Also, I'm not sure that it is any > faster (the current scheme can be done in three x86-64 instructions > too[2]), but any difference would be immeasurably tiny compared to the work > of the AEAD itself. > > The overriding interest here is to avoid having yet another nonce format. > RFC 7905 diverged from TLS 1.2 with the intent that it would align with TLS > 1.3. There would have to be a significant reason to add more complexity. > > [1] https://tools.ietf.org/html/rfc5116#section-2.1 > [2] context struct addr in rax, seq number in rcx: leaq maskOffset(%rax), > %rbx ; xorq (%rbx), %rcx ; movbeq %rcx, 4(%rdi) > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org https://www.imperialviolet.org > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --94eb2c19f3b46921690551027aa5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's worth noting that we considered a variant of this= design initially
and then decided on the XOR design instead.
<= div>

-Ekr


On Fri, = Jun 2, 2017 at 4:20 PM, Adam Langley <agl@imperialviolet.org><= /span> wrote:
On Fri, Jun 2,= 2017 at 3:33 PM, Andrey Jivsov <crypto@brainhub.org> wrot= e:
The benefits are th= at the encryption layer doesn't need to deal with a
record number or its serialization, or the mask. The state is minimal.
The nonce update code is faster and smaller (e.g. 3 instructions on x86_64)= .

I would like to thank earlier reviewers. As part of these reviews
RFC7905 was brought up. I appreciate the desire not to update the
RFC7905, but this should not interfere with the WGLC, and it's a fairly=
new stream cipher anyway.

If the= encryption layer implements the standard interface[1] then it doesn't = care about any of this anyway. Also, I'm not sure that it is any faster= (the current scheme can be done in three x86-64 instructions too[2]), but = any difference would be immeasurably tiny compared to the work of the AEAD = itself.

The overriding interest here is to avoid h= aving yet another nonce format. RFC 7905 diverged from TLS 1.2 with the int= ent that it would align with TLS 1.3. There would have to be a significant = reason to add more complexity.

[2] context struct a= ddr in rax, seq number in rcx: leaq maskOffset(%rax), %rbx ; xorq (%rbx), %= rcx ; movbeq %rcx, 4(%rdi)


Cheers

AGL
=

--
Ad= am Langley agl@= imperialviolet.org https://www.imperialviolet.org

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


--94eb2c19f3b46921690551027aa5-- From nobody Fri Jun 2 16:44:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50C21294C4 for ; Fri, 2 Jun 2017 16:44:44 -0700 (PDT) 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, 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=brainhub-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 ifMb9tU-7zbo for ; Fri, 2 Jun 2017 16:44:43 -0700 (PDT) Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::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 02BD312969E for ; Fri, 2 Jun 2017 16:44:42 -0700 (PDT) Received: by mail-pf0-x22b.google.com with SMTP id 83so498769pfr.0 for ; Fri, 02 Jun 2017 16:44:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brainhub-org.20150623.gappssmtp.com; s=20150623; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=IKrLxc/vv//n3LmhHQvR0Z8JTwUSBjZwj3hwEL+rUNQ=; b=naUHDOpaMGxosyWsjF9ftru5naqmvksZKdNIg9GMP2bWe74nkePoCwpWK1aO+gvue3 nQt83YK8VWkapA2hSciG+rdP8q8MGIl3deVnYfQqv45HejUQn24T6FAjUIUjsfecGGR2 cTFbfD2uiKEsSw8z4sb/gFsjCn4axa8uBLmEHVA3lQfFs730MZ/TSUZfheSDB5As9UGY a5A5gtQxEKXoRE9uF9Qy0bYr3wWEkEEq8WrP4Bdv3D6qgfwQsxg6Qi+89JJ8X4W198PI BuXR8WmiKRi+44XDdli+a1O2K1lbDDEBfH/H83xH4LUhd4bfvJcJXK6fC8eUFjfbESt5 ouZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=IKrLxc/vv//n3LmhHQvR0Z8JTwUSBjZwj3hwEL+rUNQ=; b=jcsDH8tscGf1x/Aj5Ay/cwV/4x8kR8GHmrf94fZkGJmOnC3tMZKLJ4IGQGiobmC8/d +Jaa1pDGzWZV632r3yGhiYu+guV1t4kPTtczfJuxsd4BjDz8gZQCOveyaivfeotjFQtc pZqRLtiG7kiMqHaSLf3aAmyY7iKyCXKpELv8PnkIfopYVtjTItOrKdBqszi1iVr4E+PL wKUI/ecr8w3yLRlml+cPS9N94nSxQjiP/A1QLrgLj2jjmOZa+HWmoY4qeFK3tRAmbjtI PC1/ndCT+K27PDlEQeg5WfcEcB9iCPSYAMNk9YkGt8b3842oDoB3j2CHhS1az2LzOB8a xfWw== X-Gm-Message-State: AODbwcDAQ9orZX1HS7SZAPCLszEBqsJbNdgHlHDASv63ZwafMWLSm/BB 2MObUKcqJ4BP04att3I= X-Received: by 10.84.231.1 with SMTP id f1mr2291918plk.258.1496447082094; Fri, 02 Jun 2017 16:44:42 -0700 (PDT) Received: from [192.168.86.93] ([104.219.106.83]) by smtp.googlemail.com with ESMTPSA id f1sm35989892pgc.8.2017.06.02.16.44.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Jun 2017 16:44:41 -0700 (PDT) Sender: Andrey To: Adam Langley References: Cc: "tls@ietf.org" From: Andrey Jivsov Message-ID: <304f5875-210d-b4cc-4410-165442be5532@brainhub.org> Date: Fri, 2 Jun 2017 16:44:39 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [TLS] Improved nonce generation method for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 23:44:45 -0000 Regarding [2], we should be counting the functionality for serialization and the increment of record number needed by the current nonce method. Serialization would need two bswaps for little-endian platforms and an increment. (We need to bring the integer into host format first, thus the roundtrip with swaps.) These are the 3 instructions that I counted: two bswaps, one increment. That's all that my method needs. If we assume that the layers are mixed together, there may be some reuse. If we consider a stronger separation, where the encryption layer is as independent as possible, it will have to do what the current TLS 1.3 prescribes independently. I am not saying that performance savings due to this proposal are significant. However, some may do encryption in hardware, while the nonce will probably always be in software. My main point here is simplicity. It seems easier to me to increment 12 bytes (suppressing the carry) in-place. On 06/02/2017 04:20 PM, Adam Langley wrote: > On Fri, Jun 2, 2017 at 3:33 PM, Andrey Jivsov > wrote: > > The benefits are that the encryption layer doesn't need to deal with a > record number or its serialization, or the mask. The state is minimal. > The nonce update code is faster and smaller (e.g. 3 instructions on > x86_64). > > I would like to thank earlier reviewers. As part of these reviews > RFC7905 was brought up. I appreciate the desire not to update the > RFC7905, but this should not interfere with the WGLC, and it's a fairly > new stream cipher anyway. > > > If the encryption layer implements the standard interface[1] then it > doesn't care about any of this anyway. Also, I'm not sure that it is any > faster (the current scheme can be done in three x86-64 instructions > too[2]), but any difference would be immeasurably tiny compared to the > work of the AEAD itself. > > The overriding interest here is to avoid having yet another nonce > format. RFC 7905 diverged from TLS 1.2 with the intent that it would > align with TLS 1.3. There would have to be a significant reason to add > more complexity. > > [1] https://tools.ietf.org/html/rfc5116#section-2.1 > [2] context struct addr in rax, seq number in rcx: leaq > maskOffset(%rax), %rbx ; xorq (%rbx), %rcx ; movbeq %rcx, 4(%rdi) > > > Cheers > > AGL > > -- > Adam Langley agl@imperialviolet.org > https://www.imperialviolet.org From nobody Fri Jun 2 16:54:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9F8112969E for ; Fri, 2 Jun 2017 16:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.401 X-Spam-Level: X-Spam-Status: No, score=-2.401 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, 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=cryptonector.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 qeRc4fkIRkSu for ; Fri, 2 Jun 2017 16:54:43 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3FA31294C4 for ; Fri, 2 Jun 2017 16:54:43 -0700 (PDT) Received: from homiemail-a66.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTP id 22CAEC002823; Fri, 2 Jun 2017 16:54:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=loANNmTQCE5Q29 fwz6GFde27sYY=; b=CfATkCiZUVn95DoY6BgdBe7cRWf7Mw0SODUu4LO6R48OcR TnFrpJv4o4BepRAPzunhEJKrKdUDukDWcroiXB+4+GtsJORF8D3mxzXg5AgRivIS PpG58i5t1C5gccSzSn1QMYXRI0w9hyN3m5/yiZQ3Nh9C6uixlgsafYeq1sGTo= Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a66.g.dreamhost.com (Postfix) with ESMTPSA id BEBA0C002824; Fri, 2 Jun 2017 16:54:42 -0700 (PDT) Date: Fri, 2 Jun 2017 18:54:39 -0500 From: Nico Williams To: Andrey Jivsov Cc: "tls@ietf.org" Message-ID: <20170602235438.GC2903@localhost> 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] Improved nonce generation method for TLS 1.3 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 02 Jun 2017 23:54:45 -0000 On Fri, Jun 02, 2017 at 03:33:46PM -0700, Andrey Jivsov wrote: > The motivation for this is stronger separation between the encryption > layer and the TLS layer. An alignment with FIPS 140 guidance is another > motivation, which tells that the IV management shall be internal (in > encryption direction). FIPS-140 may have to align with TLS 1.3. That's always an option. From nobody Sat Jun 3 03:47:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D19251287A5 for ; Sat, 3 Jun 2017 03:47:26 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 eTqxvZ4sZzl5 for ; Sat, 3 Jun 2017 03:47:24 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 564D7128896 for ; Sat, 3 Jun 2017 03:47:23 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 22B5620972; Sat, 3 Jun 2017 13:47:23 +0300 (EEST) 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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id umL59R5PVQDc; Sat, 3 Jun 2017 13:47:22 +0300 (EEST) 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 BBAFF2313; Sat, 3 Jun 2017 13:47:22 +0300 (EEST) Date: Sat, 3 Jun 2017 13:47:19 +0300 From: Ilari Liusvaara To: Victor Vasiliev Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20170603104719.GA27746@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: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 03 Jun 2017 10:47:27 -0000 On Fri, Jun 02, 2017 at 05:49:51PM -0400, Victor Vasiliev wrote: > On Thu, Jun 1, 2017 at 8:22 PM, Eric Rescorla wrote: > > > I've just gone through this thread and I'm having a very hard time > > understanding what the actual substantive argument is about. > > > > I believe at this point we mostly disagree on what specific scenarios > are and are not a concern that should be solved by TLS layer. > Replay/retry distinction might be at core for some disagreements. > > Let me lay out what I think we all agree on. > > > > 1. As long as 0-RTT is declinable (i.e., 0-RTT does not cause > > connection failures) then a DKG-style attack where the client > > replays the 0-RTT data in 1-RTT is possible. > > > > Correct. Err, how does not failing connection enable DKG-style attack? If connection failed on 0-RTT failure, the client would then presumably just establish a new one (if it can) without 0-RTT, and we are where we started (the client doesn't even gain additional knowledge, because 0-RTT ACK exists today). But failing the connection on 0-RTT failure is not nice on other grounds. > > > > 3. Allowing the attacker to generate an arbitrary number of 0-RTT > > replays without client intervention is dangerous even if > > the application implements replay-safe semantics. > > > > Correct, and the specific number is highly situational. For some attacks, it is pretty low (few dozens or less or so), especially if you can distribute across servers. > > 4. If implemented properly, both a single-use ticket and a > > strike-register style mechanism make it possible to limit > > the number of 0-RTT copies which are processed to 1 within > > a given zone (where a zone is defined as having consistent > > storage), so the number of accepted copies of the 0-RTT > > data is N where N is the number of zones. > > > > Correct. Session caches are inherently bound to a single zone. Which together with "multi-server" attacks imply that 0-RTT tickets need to be bound to a zone (when doing 0-RTT). Of course, even only using tickets for 0-RTT in one zone, while accepting them to skip signatures on others would still leave the FS problems. > > 5. Implementing the level of coherency to get #4 is a pain. > > > > Yes. Interestingly, the required coherency is quite easy for small sites (run off VPS or container), it is large sites (multiple datacenters) that have problems. -Ilari From nobody Sat Jun 3 22:43:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94E881294C7 for ; Sat, 3 Jun 2017 22:43:14 -0700 (PDT) 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 6y3uTQ45dFz1 for ; Sat, 3 Jun 2017 22:43:13 -0700 (PDT) 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 12C771294B9 for ; Sat, 3 Jun 2017 22:43:13 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id m47so37774397iti.1 for ; Sat, 03 Jun 2017 22:43:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=nkFokghS/xMNQxErpEGl80m0mFAgmMe/gvGZ5iHTKeI=; b=NrrwXtqC4viWHlL/nR77zJnXSk2bmXpzpYb12uUefv/xVFEYIJi53ND7FFcsu/rglf /YW1Awit/89l9214WnhwfC4HNAErdDojofY3kdDOy+6do7RfuAlV52PDF8sD5aNh4wnW BZKuc8tpcIFd7AYXfp1g2wxBaDaHE7YKq7fsE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=nkFokghS/xMNQxErpEGl80m0mFAgmMe/gvGZ5iHTKeI=; b=qxgmS956v3iSWObxEh4oUfrv12FIppsWn15djWsBwYjQQmgjItZLTOgrKYI0G+D6yT lR24rMR7TdHC8UL1HjohW70c/mkeK+8Q3vm5p7XnhAuE4OFY/KQG+EKUgWfMAc990NvC Q3kZuuoSWDOfijzKXWNwpXPyNy60luda2Qaj0XlDZG6P2G6yQsmESxkgog9NrQ6Qnjyg aAdymlmNYtTTmjKXl2tfGZ6arv9qD1fKm/eMmciyWuyi4UUXyaZuZ547+WiKYMz5qMJy ZHI5aZfMfvF38w9RFUnsGZO5PRpOqaiNCstDetgMOJqpgXqLxNS0y+tm/kg4VmHiZUdt oquQ== X-Gm-Message-State: AODbwcDQjTm/xvpQKI6Tj+RxK3fVA60VZR6m1EZZhdJGc8bDq6tLxtWo BOD4fksVzH4nLjYSxZBiKg== X-Received: by 10.107.204.6 with SMTP id c6mr17476572iog.166.1496554992016; Sat, 03 Jun 2017 22:43:12 -0700 (PDT) Received: from [5.5.33.201] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id 82sm12284872iok.39.2017.06.03.22.43.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 03 Jun 2017 22:43:10 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: <8B97253B-2A79-421E-BD5D-732128525520@sn3rd.com> Date: Sun, 4 Jun 2017 01:43:06 -0400 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] merging PR#998 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2017 05:43:15 -0000 All, It looks like PR#998 (https://github.com/tlswg/tls13-spec/pull/998), = which was discussed in this in this monster thread = (https://mailarchive.ietf.org/arch/msg/tls/mHxi-O3du9OQHkc6CBWBpc_KBpA), = is ready to be merged; ekr actually asked if it was okay to merge back = on 16 May. Please let list know by COB 9 June (in whatever timezone = you=E2=80=99re in) if you object to merging it and why. spt= From nobody Sun Jun 4 12:09:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB3912009C for ; Sun, 4 Jun 2017 12:09:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.801 X-Spam-Level: X-Spam-Status: No, score=-0.801 tagged_above=-999 required=5 tests=[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=-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=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 4JkaZnu3Z0ub for ; Sun, 4 Jun 2017 12:09:00 -0700 (PDT) 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 9C5BF129C4E for ; Sun, 4 Jun 2017 12:09:00 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id l14so47311118ywk.1 for ; Sun, 04 Jun 2017 12:09:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=mefLaNqynDh9u6EFgg3wLg4Tj8b8bjg6lSHx2D34Eec=; b=dNczVYbfaWySOPHhi119ANdgCS4U5pl3UgO/riXSGEt7Z3MS9Yn2SGKamoxJZqJnRF O56MQq3Q25mafTcVgBrNF/1sfCKimXqmFYrftgpSHwjCrLnTXlLujzQKDng6ED7+85gB 7Zdkhe2tYCNYlfFFwyfbkrzfVUjXT/wVfjvfyoPvL5fj4+x1kgTfmk7o+AHFgE+o/WRB mWyCImva3m1VXlxUaBN/t2aWb6kBlHSm4xdbbUfCyDMEKh/RVuCvqZPwTRAG0vnZgA0z h1UskZ5ehBv3WXRdMcrIV8dw86aCdXIpvjtNkXm8khIzTvVQotW0zUO+fQ0BbVpOlaRT iUzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=mefLaNqynDh9u6EFgg3wLg4Tj8b8bjg6lSHx2D34Eec=; b=Da7Qt/Ed0tro5EeUKZpVGdqf+GziVkMLIjV368LrOlvcQp3RsmtJsAPpL46G3IjBQM +doGzsIUi23Wbkjzz4o5faddtA9jVGbZwNsr7qz8JyTMWwOG6a7dI6gL8oM6YvAEWRQb s3myfIBBgJWOTDBquB5ApLysLglB5ETKOwnYpacpqTEmbFOPWGv8Mjjc6qbDQ4n2w5iR v0I0wuLoBNo0opC2ehGY51px1zKMHW5W1xCS1IoYNwFAfr3fR5dmVVBjbBgbWyYD3fBX NoZmpWjeFce8IquSMYxXLA/F5G/Sf/03A9TL3kf8IctSqTA3e26nWRkeE3xyCk1Tu9qM C0Xg== X-Gm-Message-State: AODbwcD2BooKe4D7XiE2ItaC//ml5iHzV4KiypuvieD+dJgPre/ScR0Y pIM16rY0fbR6rcsSzG1WNmmD3AVyPmEL X-Received: by 10.13.242.132 with SMTP id b126mr12560913ywf.95.1496603339650; Sun, 04 Jun 2017 12:08:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.222.67 with HTTP; Sun, 4 Jun 2017 12:08:58 -0700 (PDT) In-Reply-To: References: From: Bill Cox Date: Sun, 4 Jun 2017 12:08:58 -0700 Message-ID: To: Victor Vasiliev Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c035a406e6d3f0551271e58" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2017 19:09:02 -0000 --94eb2c035a406e6d3f0551271e58 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 2:39 PM, Victor Vasiliev wrote: > > Now, imagine the following attack: > > a) Between (1) and (2), the attacker resets the TCP connection, after > the client got the response and the session ticket. > b) Since the client has the ticket, it 0-RTTs the POST to take out a > lock. > c) Attacker redirects the client to another datacenter, which cannot > accept 0-RTT, so it switches to 1-RTT. > d) During (b) and (c), the attacker records a transcript of 0-RTT > request to take out a lock. > d) The rest of (2)-(6) proceed in normal fashion via client talking to > the distant datacenter. > e) Attacker replays the lock being taken out in the datacenter where > 0-RTT would succeed; the lock now is in place, and the client has > no idea about it. > > Because the application layer cannot reasonably assume that such > reordering can happen, it is not acceptable to 0-RTT the POST in #2. > A simpler attack over TLS 1.2 that has the same result: a) An active attacker waits until she sees what she believes is a lock POST request. This can happen at any time during the connection, and the flight is identified by metadata since it is encrypted. b) The attacker holds the lock request, and keeps the connection to the server alive by transmitting a byte to it every minute or so, and terminates the client connection. c) The client reconnects, and proceeds with steps 2-6 d) Attacker sends the request to obtain the lock, and now the resource is locked. For browsers, this attack seems simpler (no redirect to another data center), and more powerful (can attack at any point in the stream). It obtains the same result (locked resource), and I do not see any simple mitigation, other than to force clients to make all state changes transactional. I realize this attack requires browser retransmition, not just TLS re-transmission, so it is fundamentally different. However, isn't the result the same or worse? My feeling is that when talking to stateless 0-RTT servers, browsers should send only idempotent HTTP requests, and accept less-than-perfect FS. I also feel they should avoid attempts at client auth over 0-RTT. However, when talking to servers that prevent replay (but not re-transmission) I think browsers should be free to send any HTTP requests over 0-RTT, and also attempt client auth. The security properties of 0-RTT data are still different, but for browsers, where it does not matter whether the re-transmission is in the browser or TLS layer, the security seems equivalent to me. Bill --94eb2c035a406e6d3f0551271e58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 2, 2017 at 2:39 PM, Victor Vasiliev <vasilvv@google.com>= wrote:

Now, = imagine the following attack:

=C2=A0 a) Between (1= ) and (2), the attacker resets the TCP connection, after
=C2=A0 = =C2=A0 =C2=A0the client got the response and the session ticket.
= =C2=A0 b) Since the client has the ticket, it 0-RTTs the POST to take out a=
=C2=A0 =C2=A0 =C2=A0lock.
=C2=A0 c) Attacker redirects= the client to another datacenter, which cannot
=C2=A0 =C2=A0 =C2= =A0accept 0-RTT, so it switches to 1-RTT.
=C2=A0 d) During (b) an= d (c), the attacker records a transcript of 0-RTT
=C2=A0 =C2=A0 = =C2=A0request to take out a lock.
=C2=A0 d) The rest of (2)-(6) p= roceed in normal fashion via client talking to
=C2=A0 =C2=A0 =C2= =A0the distant datacenter.
=C2=A0 e) Attacker replays the lock be= ing taken out in the datacenter where
=C2=A0 =C2=A0 =C2=A00-RTT w= ould succeed; the lock now is in place, and the client has
=C2=A0= =C2=A0 =C2=A0no idea about it.

Because the applic= ation layer cannot reasonably assume that such
reordering can hap= pen, it is not acceptable to 0-RTT the POST in #2.
<= /div>

A simpler attack over TLS 1.2 that ha= s the same result:

a) An active attacker waits unt= il she sees what she believes is a lock POST request.=C2=A0 This can happen= at any time during the connection, and the flight is identified by metadat= a since it is encrypted.
b) The attacker holds the lock request, = and keeps the connection to the server alive by transmitting a byte to it e= very minute or so, and terminates the client connection.
c) The c= lient reconnects, and proceeds with steps 2-6
d) Attacker sends t= he request to obtain the lock, and now the resource is locked.
For browsers, this attack seems simpler (no redirect to anothe= r data center), and more powerful (can attack at any point in the stream).= =C2=A0 It obtains the same result (locked resource), and I do not see any s= imple mitigation, other than to force clients to make all state changes tra= nsactional.=C2=A0 I realize this attack requires browser retransmition, not= just TLS re-transmission, so it is fundamentally different.=C2=A0 However,= isn't the result the same or worse?

My feelin= g is that when talking to stateless 0-RTT servers, browsers should send onl= y idempotent HTTP requests, and accept less-than-perfect FS.=C2=A0 I also f= eel they should avoid attempts at client auth over 0-RTT.=C2=A0 However, wh= en talking to servers that prevent replay (but not re-transmission) I think= browsers should be free to send any HTTP requests over 0-RTT, and also att= empt client auth.=C2=A0 The security properties of 0-RTT data are still dif= ferent, but for browsers, where it does not matter whether the re-transmiss= ion is in the browser or TLS layer, the security seems equivalent to me.

Bill
--94eb2c035a406e6d3f0551271e58-- From nobody Sun Jun 4 12:36:29 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC71D1293E3 for ; Sun, 4 Jun 2017 12:36:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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=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 sBEqSJNte5Lf for ; Sun, 4 Jun 2017 12:36:26 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002: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 6CB67128BB6 for ; Sun, 4 Jun 2017 12:36:26 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id o9so11979443yba.3 for ; Sun, 04 Jun 2017 12:36:26 -0700 (PDT) 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=BOuD+JzVcQiXa9kZixyaPT6KoFnNgJU4coceprHAFPw=; b=e4OTYTSZXekkkN8dIziJMB/7i8fMKVfbVJtWCFoUz73Y8/rrqJhT0jDTo+gw1DglEI F1OB82rlPZmv1tvcOdwA+vyriaHir23Z0rTt7GGD9DlPBdlyMZshEaQf5T6HuDu4R3sM FI30CXQmA/Ze42Wr1HeBYiNRW3j6bswy/utYLtQiOwPmeIKYzJb8eg0yYT0bK3LJWFAe xJbtRuGgwFrWRcSBJSaaJ+XVjcSHcVIz9M0rnR2QsbbvpaXhuMb87e68QQ6CGYozFpJX lXEJI0puAxS95n2vizDUDkk+i563B6lMcczY4amHvQgquUY6nmrfRpeYDIMyGsLgw/Iq EYMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=BOuD+JzVcQiXa9kZixyaPT6KoFnNgJU4coceprHAFPw=; b=bP4wcVXNnQLKag4Cc00AXVcrMpnf0XFRS9TJ4bOhXG9XBFLlnn0yX7dPq64ItfoGe8 njUpXM1CdlX11IbfrDRwbcX/FmUOBOJJJoaFb+4MoyWNjmBrgJCBIIKD4TwLZRboNQs+ nF8OZh3hXyeJh0sAMBWJ0Yv0VEjUfKJjO9F5Em+7MuBdbKZl4MjOHRom7ZCZGukx/orx ycbVvin7PyRGI/4IcP0BbqF6XHqjmQA0Nr+8KOGdIJ0CXC/90lyrebx7hl5VR1vgd2gH 0z0dm6jir0sbaSPI/ATzUWotuRj7FzzGsvTAWFHzFJ5HRc2tMzlKAARHW64AhF6cK0Yn MwjA== X-Gm-Message-State: AODbwcBha5+cal8MjUDjWNiJFI6OY3kayfa5wXMlt5PxsOQFj2vMoJ7p 5OEKUub+zbrE+x8CchNkHoDZNnfzU652 X-Received: by 10.37.33.70 with SMTP id h67mr7254780ybh.159.1496604985697; Sun, 04 Jun 2017 12:36:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.93.70 with HTTP; Sun, 4 Jun 2017 12:36:24 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Sun, 4 Jun 2017 12:36:24 -0700 Message-ID: To: Eric Rescorla Cc: Victor Vasiliev , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1143ebc68abf8e0551278027" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2017 19:36:28 -0000 --001a1143ebc68abf8e0551278027 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 2, 2017 at 2:25 PM, Eric Rescorla wrote: > > Sure. For the sake of clarify, I'm going to suggest we call: > > - replay == the attacker re-sends the data with no interaction > with the client > - retransmission == the client re-sends (possibly with some slight > changes) > O.k., cool. > 7. With the current design, clients have no way of knowing what, if any, > anti-replay mechanisms the servers are using. Thus, they cannot be > sure that servers are ensuring at-most-once semantics for the 0-RTT > data (at-most-twice if the client retransmits in response to 0-RTT > failure) [0]. This makes it difficult for clients to know what is > safe to send in 0-RTT. > > 8. The more broadly distributed the information required to process > a session ticket (on the server), the worse the FS situation is, > with session tickets encrypted under long-lived keys being the > worst. > > I note that you suggest separating out 0-RTT tickets and resumption > tickets, but I don't actually see how that changes matters. As Ilari > notes, it is possible to say that a ticket cannot be used for 0-RTT > and if you have a ticket which can be used for resumption globally > but for 0-RTT at just one site, the server can implement that policy > unilaterally. > Yep, that's right, and should work. -- Colm --001a1143ebc68abf8e0551278027 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 2, 2017 at 2:25 PM, Eric Rescorla <ekr@rtfm.com> = wrote:
Sure. For the sa= ke of clarify, I'm going to suggest we call:

-= replay =3D=3D the attacker re-sends the data with no interaction
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 with the client
- retr= ansmission =3D=3D the client re-sends (possibly with some slight
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 chang= es)

O.k., cool.=C2=A0
=C2=A0
7. With t= he current design, clients have no way of knowing what, if any,
= =C2=A0 =C2=A0anti-replay mechanisms the servers are using. Thus, they canno= t be
=C2=A0 =C2=A0sure that servers are ensuring at-most-once sem= antics for the 0-RTT
=C2=A0 =C2=A0data (at-most-twice if the clie= nt retransmits in response to 0-RTT
=C2=A0 =C2=A0failure) [0]. Th= is makes it difficult for clients to know what is
=C2=A0 =C2=A0sa= fe to send in 0-RTT.

8. The more broadly distribut= ed the information required to process
=C2=A0 =C2=A0a session tic= ket (on the server), the worse the FS situation is,
=C2=A0 =C2=A0= with session tickets encrypted under long-lived keys being the
= =C2=A0 =C2=A0worst.

I note that you suggest separa= ting out 0-RTT tickets and resumption
tickets, but I don't ac= tually see how that changes matters. As Ilari
notes, it is possib= le to say that a ticket cannot be used for 0-RTT
and if you have = a ticket which can be used for resumption globally
but for 0-RTT = at just one site, the server can implement that policy
unilateral= ly.

Yep, that's right, and = should work.=C2=A0


--
Colm
--001a1143ebc68abf8e0551278027-- From nobody Sun Jun 4 13:25:58 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66288126E01; Sun, 4 Jun 2017 13:25:56 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 oQ9jNU31ZrJ0; Sun, 4 Jun 2017 13:25:55 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 13AE41200E5; Sun, 4 Jun 2017 13:25:54 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v54KMOfR026533; Sun, 4 Jun 2017 21:25:49 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=qRy6BeeCQejrPTM9Y/hspBi+BPSQGBNkhPPWHf3Zqyk=; b=d0uDn+M0tDRPVmSSfiTiyzPxiKb4O7lZzIHvXkiXOcv0FBmmhAgQI2YPIKpVvH48vtpa 5+Bylz+rl86k1RTdN9VzS2ztgVYTdx3XBporzKzaoN/rxi0Z1/5jfgvvOxWYGQ1Qn63l rDLMB/XEEToNc82ytuoW5+F9SNzWcbmsSmbtjGLMNgtD++ohR/9S7WU258Oz54akehw2 bvR63/H6wybY+6UHd7s24iQ9+zSTSUPF5z5+XNXNIHXMNPel1EjEJPFQ9HpyOKZEYhtk 2Ideq9syh1Q6wugh3yUbyWTyelwEaP7s1y6+10eVe5k987sDtuVYr3sM/5Eh+HZyMZjt Qg== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2aunh86x7h-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Jun 2017 21:25:48 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v54KLKoZ031705; Sun, 4 Jun 2017 16:25:47 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint1.akamai.com with ESMTP id 2aureum1yg-1; Sun, 04 Jun 2017 16:25:47 -0400 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 BF52A1FC7B; Sun, 4 Jun 2017 20:25:46 +0000 (GMT) To: Toerless Eckert Cc: "ops-dir@ietf.org" , "" , Benoit Claise , "sec-ads@ietf.org" , "ops-ads@ietf.org" , ops-chairs@ietf.org References: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de> <20170602132833.GE12522@faui40p.informatik.uni-erlangen.de> From: Benjamin Kaduk Message-ID: <2f5c3b10-0ad0-466a-03ef-495fa6acb7bc@akamai.com> Date: Sun, 4 Jun 2017 15:25:46 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170602132833.GE12522@faui40p.informatik.uni-erlangen.de> Content-Type: multipart/alternative; boundary="------------97E0785567422C2D0666B8FD" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-04_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706040392 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-04_15:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706040393 Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2017 20:25:56 -0000 This is a multi-part message in MIME format. --------------97E0785567422C2D0666B8FD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/02/2017 08:28 AM, Toerless Eckert wrote: > Another candidate use case coming to mind eg: auditing tht is required in many eg: financial > environments. In the past i have seen even the requirement for the whole data streams to be unencrypted > for auditing. Maybe that market segment would also be able to get more privacy but maintain a > relevant level of auditing if the auditing relevant class of information was visible via > the cert. That use case has been extensively discussed (look for the thread "Industry Concerns about TLS 1.3", also a fair bit of hallway discussions), and was not seen to provide a compelling argument for any change in TLS 1.3. There are purely server-side options that should be able to provide the necessary functionality (crypto details omitted for now). -Ben --------------97E0785567422C2D0666B8FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/02/2017 08:28 AM, Toerless Eckert wrote:
Another candidate use case coming to mind eg: auditing tht is required in many eg: financial
environments. In the past i have seen even the requirement for the whole data streams to be unencrypted
for auditing. Maybe that market segment would also be able to get more privacy but maintain a
relevant level of auditing if the auditing relevant class of information was visible via
the cert.

That use case has been extensively discussed (look for the thread "Industry Concerns about TLS 1.3", also a fair bit of hallway discussions), and was not seen to provide a compelling argument for any change in TLS 1.3.  There are purely server-side options that should be able to provide the necessary functionality (crypto details omitted for now).

-Ben
--------------97E0785567422C2D0666B8FD-- From nobody Sun Jun 4 13:51:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF310129420 for ; Sun, 4 Jun 2017 13:51:54 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 k-E7bQKH-cm3 for ; Sun, 4 Jun 2017 13:51:53 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 A08BB128D2E for ; Sun, 4 Jun 2017 13:51:53 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v54KkwMR014009; Sun, 4 Jun 2017 21:51:51 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=D3Tx06jx1mV6DoxTznEKcM9qrHqSEhDznZyfZDkuRy8=; b=H66kJvAlxhNNnzV+4Hpu2Yn0HpxaEOBn0SxolqjVro72zbPSZ7h3h1hsNweeEeC+1GXf UKusWsxw8mOZXyNBKMGzMP/dPXaNuTNpFa8aADDc6PMzYFbQnsKAG5iGUB56qMZgNzWo 9zlq80Xlm+2ErynbtBWy4XWOKlPqQJ06zhv3RgRw1BeGit8N34gidy6k2d3xvvHntdea TpU++zhbVggIuRJsAomuQIXxV3EfQZy82MvuLpkHfqcC6HsJor9UKbNPiC1YXvCzIYHX wiUhuIZBFIjY3ogWArawkIufyKlzk8dgNXfWt1uvZM51Dv532TtDgKWwDNlbXhH3h5+0 LQ== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2aumn3frs7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Jun 2017 21:51:51 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v54Kp7P1032638; Sun, 4 Jun 2017 16:51:50 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2avfe58v3a-1; Sun, 04 Jun 2017 16:51:50 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 23C7B80059; Sun, 4 Jun 2017 14:51:50 -0600 (MDT) To: Bill Cox Cc: "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <56993d9b-d642-13e7-ba1d-17d8347e0294@akamai.com> Date: Sun, 4 Jun 2017 15:51:49 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A922BC15B850B2436763505E" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-04_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=2 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706040402 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-04_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706040400 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2017 20:51:55 -0000 This is a multi-part message in MIME format. --------------A922BC15B850B2436763505E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/04/2017 02:08 PM, Bill Cox wrote: > My feeling is that when talking to stateless 0-RTT servers, browsers > should send only idempotent HTTP requests, and accept > less-than-perfect FS. I also feel they should avoid attempts at > client auth over 0-RTT. However, when talking to servers that prevent > replay (but not re-transmission) I think browsers should be free to > send any HTTP requests over 0-RTT, and also attempt client auth. The > security properties of 0-RTT data are still different, but for > browsers, where it does not matter whether the re-transmission is in > the browser or TLS layer, the security seems equivalent to me. I think we're at a point where multiple people have expressed what their (subjective) feeling on the desired behavior is, and those feelings are not in agreement. So, some more concrete reasoning and deductions seem required in order for such contributions to be useful towards reaching consensus. -Ben P.S. It seems pretty well established that a client will not in general have a good idea whether it's talking to a server that prevents replay or is stateless. --------------A922BC15B850B2436763505E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/04/2017 02:08 PM, Bill Cox wrote:
My feeling is that when talking to stateless 0-RTT servers, browsers should send only idempotent HTTP requests, and accept less-than-perfect FS.  I also feel they should avoid attempts at client auth over 0-RTT.  However, when talking to servers that prevent replay (but not re-transmission) I think browsers should be free to send any HTTP requests over 0-RTT, and also attempt client auth.  The security properties of 0-RTT data are still different, but for browsers, where it does not matter whether the re-transmission is in the browser or TLS layer, the security seems equivalent to me.

I think we're at a point where multiple people have expressed what their (subjective) feeling on the desired behavior is, and those feelings are not in agreement.

So, some more concrete reasoning and deductions seem required in order for such contributions to be useful towards reaching consensus.

-Ben

P.S. It seems pretty well established that a client will not in general have a good idea whether it's talking to a server that prevents replay or is stateless.
--------------A922BC15B850B2436763505E-- From nobody Sun Jun 4 13:57:10 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7EC129B2C for ; Sun, 4 Jun 2017 13:57:08 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 la-yyq4CJndm for ; Sun, 4 Jun 2017 13:57:07 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 C657A126579 for ; Sun, 4 Jun 2017 13:57:06 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v54KquSH022060; Sun, 4 Jun 2017 21:57:06 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=2r/PlPAamYfl6IZBBWvcWp6s15tAB8jGJV0HoRZzbeU=; b=FfO5fZS+c513zlPBU+SEBGQx58ug2rSrzT/5uGlwtMOwa5tEUBJoxy27aIGFpFovL8oB /5RMCr6O17vx1zs8CLpr3Rn1pYA29Ulfu/wYyccg5SAUy6OauFGys5B3RXR1QvrgejC5 sVPqCUGhmboQrYpey2GI+ZYoiEcdPfpyIXFZR+G8Jew6sx1XTKTkrBfWyO/EL6iqSyRJ pi7YebkEuF1QZvlbpZjpiX+N3Vy8wsCeCej8Pfvgspsk4D6Z/6q3vLChu17gJMUMhw37 urH2pNqPnGnSaBTdjzc2MM8UZrRK/STcexzA8Ev1u9iEJ822mxD7pQPSLJ3t6/zkl2cU 7Q== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2aumcn7suw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 04 Jun 2017 21:57:05 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v54KubuT011649; Sun, 4 Jun 2017 16:57:05 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2aureutv4e-1; Sun, 04 Jun 2017 16:57:05 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 7F20E80052; Sun, 4 Jun 2017 14:57:04 -0600 (MDT) To: Victor Vasiliev , Eric Rescorla Cc: "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <6c25e6e2-fd9d-ff9d-05a5-5429c87286db@akamai.com> Date: Sun, 4 Jun 2017 15:57:04 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------DFFA1FC69F51CFBA6AD1854C" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-04_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706040404 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-04_16:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706040402 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2017 20:57:09 -0000 This is a multi-part message in MIME format. --------------DFFA1FC69F51CFBA6AD1854C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/02/2017 04:49 PM, Victor Vasiliev wrote: > > 4. If implemented properly, both a single-use ticket and a > strike-register style mechanism make it possible to limit > the number of 0-RTT copies which are processed to 1 within > a given zone (where a zone is defined as having consistent > storage), so the number of accepted copies of the 0-RTT > data is N where N is the number of zones. > > > Correct. Session caches are inherently bound to a single zone. I think we covered this in a couple other messages in a different subthread, but to be super-clear, 1-RTT session caches can be scoped to a larger zone than 0-RTT acceptability, at the server's unilateral discretion. -Ben --------------DFFA1FC69F51CFBA6AD1854C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/02/2017 04:49 PM, Victor Vasiliev wrote:
4. If implemented properly, both a single-use ticket and a
   strike-register style mechanism make it possible to limit
   the number of 0-RTT copies which are processed to 1 within
   a given zone (where a zone is defined as having consistent
   storage), so the number of accepted copies of the 0-RTT
   data is N where N is the number of zones.

Correct.  Session caches are inherently bound to a single zone.

I think we covered this in a couple other messages in a different subthread, but to be super-clear, 1-RTT session caches can be scoped to a larger zone than 0-RTT acceptability, at the server's unilateral discretion.

-Ben
--------------DFFA1FC69F51CFBA6AD1854C-- From nobody Sun Jun 4 16:08:42 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A70612E058 for ; Sun, 4 Jun 2017 16:08: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, HTML_MESSAGE=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=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 hzVGbjU7Jj-T for ; Sun, 4 Jun 2017 16:08:40 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 173DC127B5A for ; Sun, 4 Jun 2017 16:08:40 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v54N89XO018451; Mon, 5 Jun 2017 00:08:32 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=cfDdLOXnirJwTtQMnA1m5NuZ7pvq83SCNJNrRhyNydg=; b=mAVPnLUIh15YBrr686uSMn7/ZI8BWLttCjxR0NjGe8EldSgokCqZK2QhyQDWHIFlLZ26 YVzIr7lSebBGVdg7tICBdpJXotR6YdwVqpM9VQn86jt1jozq4xcbuNO2UKtmYS3Kowia WSF7sPbHpmXap8Y3xP2T8R6mr/amKlauK5z83eEcNRbvYs8kyTMxIgivTKqsR5duBSv6 G9S713DfPm06c0zOLdsKF/MVQI07F5PxCgQFn07WMK/duyUPgdP/4aEklMBWj7LS4yEf kWoNdr0UKzrnNeimVlpcgIereXT5Og3FtWYvBOj5QDSAMD9vDnXrXf60xZJZRi8oxfrc 6Q== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050102.ppops.net-00190b01. with ESMTP id 2auj6b04pp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 05 Jun 2017 00:08:32 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v54N68JQ010263; Sun, 4 Jun 2017 19:08:31 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2avfe591d5-1; Sun, 04 Jun 2017 19:08:31 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 3AFDA80052; Sun, 4 Jun 2017 17:08:31 -0600 (MDT) To: Victor Vasiliev , =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= Cc: "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <3a76f4ba-e514-9935-044c-6a231b30c4a1@akamai.com> Date: Sun, 4 Jun 2017 18:08:30 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------49A9AEEBA2442C9E8A1C7659" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-04_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706040445 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-04_17:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706040446 Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 04 Jun 2017 23:08:41 -0000 This is a multi-part message in MIME format. --------------49A9AEEBA2442C9E8A1C7659 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/01/2017 03:50 PM, Victor Vasiliev wrote: > > To clarify, I am not suggesting that two streams would help. > I completely > agree with you that two streams is not going to mitigate the > DKG attack or > others. What I meant is that 0-RTT inherently has slightly > different > properties from 1-RTT and must be used with that in mind. > Specifically, I > meant that it will not be enabled for applications by default, > and HTTP clients > would only allow it for methods that RFC 7231 defines as safe. > > > Well in the real world, I think it'll be pervasive, and I even > think it /should/ be. We should make 0-RTT that safe and remove > the sharp edges. > > > Are you arguing that non-safe requests should be allowed to be sent > via 0-RTT? > Because that actually violates reasonable expectations of security > guarantees > for TLS, and I do not believe that is acceptable. > Do we have a good example of why a non-safe HTTP request in 0-RTT would lose specific properties required for security? If so, that seems like a good thing to include in the TLS 1.3 spec as an example of what can go wrong. -Ben --------------49A9AEEBA2442C9E8A1C7659 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/01/2017 03:50 PM, Victor Vasiliev wrote:
To clarify, I am not suggesting that two streams would help.  I completely
agree with you that two streams is not going to mitigate the DKG attack or
others.  What I meant is that 0-RTT inherently has slightly different
properties from 1-RTT and must be used with that in mind.  Specifically, I
meant that it will not be enabled for applications by default, and HTTP clients
would only allow it for methods that RFC 7231 defines as safe.
Well in the real world, I think it'll be pervasive, and I even think it /should/ be. We should make 0-RTT that safe and remove the sharp edges. 

Are you arguing that non-safe requests should be allowed to be sent via 0-RTT?
Because that actually violates reasonable expectations of security guarantees
for TLS, and I do not believe that is acceptable.


Do we have a good example of why a non-safe HTTP request in 0-RTT would lose specific properties required for security?  If so, that seems like a good thing to include in the TLS 1.3 spec as an example of what can go wrong.

-Ben
--------------49A9AEEBA2442C9E8A1C7659-- From nobody Sun Jun 4 20:06:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340C21201F8 for ; Sun, 4 Jun 2017 20:06:40 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 2iPn353bAgxU for ; Sun, 4 Jun 2017 20:06:39 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 D888C120046 for ; Sun, 4 Jun 2017 20:06:38 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id o9so13297460yba.3 for ; Sun, 04 Jun 2017 20:06:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=VwVVzBux2im/Xl0ouPwAOJt7M1mqY3Gpr6Xq5dhTxGk=; b=dp6DwetmxxT6omU0RlnKgHljdlhNIJKHrdyUhBjOu96QhXtA46og3VZjpNw2oohOD8 4es3/eGE7lV9pvKa492D0N+a5TiTI2GohNxAn5l5HL7oek/kFoMsxikb4XC3czcE24FN v4tyPFiRoarw5+yO+logGgCk7xneZQvpzeMLEI14ZNdblj5NtMeBZnsfWefzWVaVVAqt lIC1//wvA8rT0K0BmGRxdmXzQStc+k+3euiGQlmOAMVb3Kv7budX9fLXP5MD1ILQiLul JSv1W15X7ptqPZEwYm/y6FXBK5gy8sX1lO0JDokV5jI7N8ahBj4TuwZS9a7CGd86g9Pg h2wA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=VwVVzBux2im/Xl0ouPwAOJt7M1mqY3Gpr6Xq5dhTxGk=; b=NdrU4pITjUTOTzdCgNLUnFuhLC4h8jhpTPFmkm8+druionxSgY/VvSo/MNRFDSkprr U2SxljIXijZECaWpWsd9w2x4uC2aGvDqmxhK1AK5BF4Tfd9KIBJGwS3Ik8CNOujJclrZ UgYn1MSDfGuuwKy5wbikMNR8r+cwokNduUgNkxW70R1X2u/HymkW0KCLGY7nGoc9TkMO YNH4stVNlmkT7XPKqlubmW5WRzJOOXvMmDaH3031OmY2YKi+WhIcQX/ssNgr8i5+tHzg k+xfXI79QSDUUTzgfNQhitFXe0jpBDXkI2cMoo3pWsj9EeeRFaPuEeCW2/KFR3lNmHaT PN1g== X-Gm-Message-State: AODbwcAHCfY1BzG5eJzDDp2X3pV6pNSHBEXsWUblIGjTeG4IqshRaZME xKRnG3V7XLDpjyTuKavnBfoXEnItMeGP9dQ= X-Received: by 10.37.50.5 with SMTP id y5mr4792871yby.204.1496631997164; Sun, 04 Jun 2017 20:06:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.222.67 with HTTP; Sun, 4 Jun 2017 20:06:36 -0700 (PDT) In-Reply-To: <3a76f4ba-e514-9935-044c-6a231b30c4a1@akamai.com> References: <3a76f4ba-e514-9935-044c-6a231b30c4a1@akamai.com> From: Bill Cox Date: Sun, 4 Jun 2017 20:06:36 -0700 Message-ID: To: Benjamin Kaduk Cc: Victor Vasiliev , =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1146df528dbdd405512dca1e" Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jun 2017 03:06:40 -0000 --001a1146df528dbdd405512dca1e Content-Type: text/plain; charset="UTF-8" On Sun, Jun 4, 2017 at 4:08 PM, Benjamin Kaduk wrote: > > Do we have a good example of why a non-safe HTTP request in 0-RTT would > lose specific properties required for security? If so, that seems like a > good thing to include in the TLS 1.3 spec as an example of what can go > wrong. > > -Ben > I like the example of a POST request saying "send Alice $10". It is a request that sophisticated web services will avoid, yet many smaller and less security savvy sites will continue to support requests like this, so I think it is worth considering. Bill --001a1146df528dbdd405512dca1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 4, 2017 at 4:08 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
=20 =20 =20

Do we have a good example of why a non-safe HTTP request in 0-RTT would lose specific properties required for security?=C2=A0 If so, that seems like a good thing to include in the TLS 1.3 spec as an example of what can go wrong.

-Ben

I like the example = of a POST request saying "send Alice $10".=C2=A0 It is a request = that sophisticated web services will avoid, yet many smaller and less secur= ity savvy sites will continue to support requests like this, so I think it = is worth considering.

Bill
--001a1146df528dbdd405512dca1e-- From nobody Sun Jun 4 21:17:48 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF7CF126D73 for ; Sun, 4 Jun 2017 21:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 LIFSEWX-tq9k for ; Sun, 4 Jun 2017 21:17:45 -0700 (PDT) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (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 46124124234 for ; Sun, 4 Jun 2017 21:17:45 -0700 (PDT) Received: by mail-wm0-x242.google.com with SMTP id g15so27809258wmc.2 for ; Sun, 04 Jun 2017 21:17:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=VtXGQuI2XH/cAN10QG9OIN66ExvNzvEkW5FiblDVP98=; b=GCnAA4T6ZpgOiH5XSSzaq49RSb6cYDqSqu99fjKkKeOo6hBdVD/sidUvMntHrG4IuN rJ8r/Tr8x4qrA8bI/STLbINyBiK9i6M8uSybbdDfYBafOclfkNcB4C4pW+C+NxO+LOUh 7bUqlE4dlnKdm8IsHf5Iptx7/LR66PMoU+1RZXzjfnu9w5FTao3667DvuTpO+AryzqgI WkOHgdEoPb5AKTmQ1veRmmz4YVlZuLCXbhqjHmbRhm+Vep/i7St2qoKrVD9FCtGRpmIr ubZw39LTgDvmBoDTvF2Cx4GLtnLLX802ieCaZWCR5kwu+3nCzf/zKzRvTaHLTwj49Hb/ czoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=VtXGQuI2XH/cAN10QG9OIN66ExvNzvEkW5FiblDVP98=; b=HtUgkjxVLd8gvTFO4uosYuGf+IEsxd1oGf/B+uOBIXCNXHSyNfEV1W44igPS3SNKl3 AdjPQvM57BDZ1IM1yxEJGsZrbW1o6XJNK8QBfSoA2zQeLwrYomTjEStnewJh5GZYfmNF Q+lmh95GugMlSJUMG11/RdiYa90zK6LQZpikZMPxSGRADPhG+YTDD7URjox/x071iEB4 d3CCKldXirOZhUTokSnQezej7A7nkToIkHKIvORBEAxGhDtbeI96UmhPp1pw3bErPgd3 EF559coKQc8Sr1c/ocjrMuYMZA6SGjmhZ08TxJm0+LIpuoNOjD93PlXihBO/d2C9lBIu fD+Q== X-Gm-Message-State: AODbwcC+IagKYK9i1GeHhe+9gSJNhxttfVXKTCYwHI6iqYhqBbeyR4xl cwKnRl8plejtYA== X-Received: by 10.28.215.5 with SMTP id o5mr2746389wmg.124.1496636263760; Sun, 04 Jun 2017 21:17:43 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id t8sm27943874wrc.28.2017.06.04.21.17.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 04 Jun 2017 21:17:42 -0700 (PDT) From: Yoav Nir Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_70C4DBF4-6BCB-4E12-9633-5C2F72BD5892"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Mon, 5 Jun 2017 07:17:38 +0300 In-Reply-To: Cc: Benjamin Kaduk , "tls@ietf.org" To: Bill Cox References: <3a76f4ba-e514-9935-044c-6a231b30c4a1@akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Security review of TLS1.3 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 05 Jun 2017 04:17:47 -0000 --Apple-Mail=_70C4DBF4-6BCB-4E12-9633-5C2F72BD5892 Content-Type: multipart/alternative; boundary="Apple-Mail=_D70B53EC-F2C0-46D9-9D90-572B36F3CDDC" --Apple-Mail=_D70B53EC-F2C0-46D9-9D90-572B36F3CDDC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 5 Jun 2017, at 6:06, Bill Cox wrote: >=20 > On Sun, Jun 4, 2017 at 4:08 PM, Benjamin Kaduk > wrote: >=20 > Do we have a good example of why a non-safe HTTP request in 0-RTT = would lose specific properties required for security? If so, that seems = like a good thing to include in the TLS 1.3 spec as an example of what = can go wrong. >=20 > -Ben >=20 > I like the example of a POST request saying "send Alice $10". It is a = request that sophisticated web services will avoid, yet many smaller and = less security savvy sites will continue to support requests like this, = so I think it is worth considering. >=20 I once saw a router with an HTTPS administration UI that would respond = as you=E2=80=99d expect to: GET mainpage.html?action=3DrebootDevice Worse. The router was a firewall and this worked: GET mainpage.html?action=3DdisablePolicy Yes. GET. POST also worked, but for some reason the WebUI generated = POSTs. Of course, it was really secure because the GET was accompanied by a = cookie, but I guess the cookie would fit in the early data. Not sure if = it would survive a reboot, though. Yoav --Apple-Mail=_D70B53EC-F2C0-46D9-9D90-572B36F3CDDC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 5 Jun 2017, at 6:06, Bill Cox <waywardgeek@google.com> wrote:

On Sun, = Jun 4, 2017 at 4:08 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
=20 =20 =20

Do we have a good example of why a non-safe HTTP request in 0-RTT would lose specific properties required for security?  If so, = that seems like a good thing to include in the TLS 1.3 spec as an example of what can go wrong.

-Ben

I = like the example of a POST request saying "send Alice $10".  It is = a request that sophisticated web services will avoid, yet many smaller = and less security savvy sites will continue to support requests like = this, so I think it is worth considering.


I once saw a router with an HTTPS administration UI that = would respond as you=E2=80=99d expect to:

GET = mainpage.html?action=3DrebootDevice

Worse. The router was a firewall and = this worked:

GET= mainpage.html?action=3DdisablePolicy

Yes.  GET. POST also worked, but = for some reason the WebUI generated POSTs.

Of course, it was really secure because = the GET was accompanied by a cookie, but I guess the cookie would fit in = the early data. Not sure if it would survive a reboot, though.

Yoav



= --Apple-Mail=_D70B53EC-F2C0-46D9-9D90-572B36F3CDDC-- --Apple-Mail=_70C4DBF4-6BCB-4E12-9633-5C2F72BD5892 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZNNtjAAoJELhJCxUKWMyZRhwH/3wBCGWv/damrK/6i3IISew2 KDQzyYuJ7SfNRX/I+D6Wl8Mdc4p0CxjCvM9NqZTvP8uR6agOwKWfGVt3wWgCnMcu 7mKq12H1MLREBX24ehDjcLAVs8kbw0x9W6vYv5Hh26Z/7oyMP6HsDrSo2/kQfPEx SXt01Uxmp83KOXaZ77ynATKgMVT8yzA/jnVYJB6fT9OqQ3AinN24v9F9mEBA0CLk UNyGwOtYcjw5i+mqvgDt8mpdt45o8XEDK1HPRvk323Tv3Co2sJScQS9E4imUfRHp fJ6sbrxo8wL8x2UvadS+k7Xdb7qFrsWa/dOCCRxziF70dTyJZYGCs9xCNM50cgE= =v55L -----END PGP SIGNATURE----- --Apple-Mail=_70C4DBF4-6BCB-4E12-9633-5C2F72BD5892-- From nobody Tue Jun 6 00:20:12 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB23E1200CF for ; Tue, 6 Jun 2017 00:20:09 -0700 (PDT) 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 qE7VU6wqzBpf for ; Tue, 6 Jun 2017 00:20:08 -0700 (PDT) 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 4E285129C12 for ; Tue, 6 Jun 2017 00:20:08 -0700 (PDT) Received: by mail-it0-x229.google.com with SMTP id m47so85520010iti.1 for ; Tue, 06 Jun 2017 00:20:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=ez1YRW0Po6HVfUIIdax+gbnrb3hAM8J7E1uDa6USwqM=; b=mvADPYhQV8wJdXxisHLX2iz6x58lzbWLygNP6MsEW1yCN+Yd8DpxrrioOGtxUwTNZh SZHPYrVYP8ACTNe7BFVY8M0SitkBQlDwbEqZiTaNOk0L3xYTMzdmEav+d9AlAnyvX9l/ eBSURB8Z5glHCskA6Pr19R8Baur9f0U5uRtKE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=ez1YRW0Po6HVfUIIdax+gbnrb3hAM8J7E1uDa6USwqM=; b=erDUB7pAuYKn3kBBpeHL1sy1SnaSQER1wj62VIREW1gVsISw5TlgPZNAv/uVgVsthk 5yPzppMi1o3SnIbHIxbnm+WOxTrPGzAjNIeNrNAJjHqq4xfcWf4V03JjnRverSUoSzqC Z6wvrYAiaCxQwwNMquHipUrwg/xqHr0ygnf5yrWfbqKPwTMEtrGz866W5U7Ss1aMiu+8 i/yeTsENdwcPu0bK3gUFZWpcZBqo3ywAfj0kRJuRrp8bfGGrYoGzCUyqZG46AcC7F8id BpDwQJyCBeGCUEn2kmSIoS544D72DLfPkWqzurYQSvSVS5oHQkwzD0fhIm+gO1tZmYjT 6ZHQ== X-Gm-Message-State: AODbwcDHdP7M9yp3O5+ezfO74rSa26BzW5osdZl782ztKUZZSjI8LfmQ OnCUfhA/rsi2Q8ufEjazYw== X-Received: by 10.107.128.228 with SMTP id k97mr8336719ioi.115.1496733607241; Tue, 06 Jun 2017 00:20:07 -0700 (PDT) Received: from ?IPv6:2001:450:1e:232:4ba:d331:d37c:96a7? ([2001:450:1e:232:4ba:d331:d37c:96a7]) by smtp.gmail.com with ESMTPSA id d35sm14821607ioj.5.2017.06.06.00.20.05 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 00:20:06 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 6 Jun 2017 09:20:03 +0200 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2017 07:20:10 -0000 I appears that we=E2=80=99ve got enough consensus/interest to adopt = draft-ghedini-tls-certificate-compression-00 based on the WG session in = Chicago and this thread: https://mailarchive.ietf.org/arch/msg/tls/U5AmA9OerD_9zTBNWl7ZBC3-HOE Authors, Please submit draft-ietf-tls-certificate-compression at your earliest = convenience. All, I=E2=80=99ve established a GH repo at: https://github.com/tlswg/certificate-compression Victor and Alessandro are Admins so they=E2=80=99ll be copying over = their repo. Thanks!=20 J&S= From nobody Tue Jun 6 02:24:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D475A1294C9 for ; Tue, 6 Jun 2017 02:24:23 -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 u_gQ1Mm5tQbc for ; Tue, 6 Jun 2017 02:24:22 -0700 (PDT) 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 7A50F12426E for ; Tue, 6 Jun 2017 02:24:22 -0700 (PDT) Received: by mail-it0-x230.google.com with SMTP id m47so102835239iti.0 for ; Tue, 06 Jun 2017 02:24:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=yhDmRuNHbI30l/owYfE7JjPe7PDdSt15JC8QJL7Nq+M=; b=Nv+hNvilL7dtSVg1ry7ErqYs/93Dr3IKrQt4R06hCSAK8ZMZw9dHT7VAP7L1aWrjdp 0h4Squ7TZtLhL6HM0Qz1K/JIJZ3G2G1WqJjFWxF7jo9LJoOrEqF8h0uDYBsg3ETITU+O jRJQLcc0rh+7A3D0utQpc1yNmMxpHpVJqavMk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=yhDmRuNHbI30l/owYfE7JjPe7PDdSt15JC8QJL7Nq+M=; b=S16DX3z6R7aA1lKeJh1p39LyogF1Y6WQRl95fP5DfQAkicYoqO8CnhaR3WRObBUHnW je98b78GAhm5OSpzMkf2Z1wZLHO5pLcQZSe6U6IJoSzw+lz4rKipTQp29LgWQ6Fe8c35 2I8Qw3EjW1R6G0BkcZxbisMAA1RU1mhjmLg9xvX+RmYgYbpqVlI8q9XIsI/mNbU9T3wT /fhXvyMv6Q5+9LVEo0D3G/L1Rvi2WczwPrKtbvmmf6rp9VQqTL9hK2VkOFj6Xdldp6QO 9OFRKrKqhHeE3HNiIu6DI79bPFvHug21/LFyBtw8e2lvVVJUrEY13yyEmf15ez9CKZEA BVNA== X-Gm-Message-State: AODbwcDj2btMDD08J7fDIrfYaSlLG9Miy17LXvRWkCEXDh3DPgcaUI5M nCp90GaBmP3Lxd1UMTgeZA== X-Received: by 10.36.88.196 with SMTP id f187mr17382252itb.28.1496741061597; Tue, 06 Jun 2017 02:24:21 -0700 (PDT) Received: from ?IPv6:2001:450:1e:232:4ba:d331:d37c:96a7? ([2001:450:1e:232:4ba:d331:d37c:96a7]) by smtp.gmail.com with ESMTPSA id z68sm1466926itb.0.2017.06.06.02.24.20 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Jun 2017 02:24:20 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Message-Id: Date: Tue, 6 Jun 2017 11:24:15 +0200 To: "" X-Mailer: Apple Mail (2.3273) Archived-At: Subject: [TLS] IETF 99: request for agenda time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2017 09:24:24 -0000 All, You will have seen the chair's IETF 99 TLS session request on May 31st. = When the session will occur during the week has not yet been set, but = the chairs would still like get a sense of who wants to request agenda = time. The chairs need to upload a draft agenda by 20170705 so if you = would like time on the agenda please submit the request to = tls-chairs@ietf.org by 20160630. Along with your request please let us = know how long you would like. J&S= From nobody Tue Jun 6 07:23:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBC7A129461 for ; Tue, 6 Jun 2017 07:23:31 -0700 (PDT) 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 3ZS5stG-C1zX for ; Tue, 6 Jun 2017 07:23:29 -0700 (PDT) Received: from zucker.schokokeks.org (zucker.schokokeks.org [178.63.68.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC7012025C for ; Tue, 6 Jun 2017 07:23:28 -0700 (PDT) Received: from pc1 ([2001:2012:127:3e00:b3bf:56a1:a140:6086]) (AUTH: LOGIN hanno-default@schokokeks.org, TLS: TLSv1/SSLv3, 256bits, ECDHE-RSA-AES256-GCM-SHA384) by zucker.schokokeks.org with ESMTPSA; Tue, 06 Jun 2017 16:23:25 +0200 id 0000000000000045.000000005936BADD.000021E3 Date: Tue, 6 Jun 2017 16:23:24 +0200 From: Hanno =?UTF-8?B?QsO2Y2s=?= To: tls@ietf.org Message-ID: <20170606162324.4aee493b@pc1> In-Reply-To: References: X-Mailer: Claws Mail 3.15.0-dirty (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 06 Jun 2017 14:23:32 -0000 On Tue, 6 Jun 2017 09:20:03 +0200 Sean Turner wrote: > I appears that we=E2=80=99ve got enough consensus/interest to adopt > draft-ghedini-tls-certificate-compression-00 based on the WG session > in Chicago and this thread: Hi, one aspects brought up in that thread was that there is already RFC 7924, which allows certificate caching. There's also AIA, which allows a client to fetch intermediate certificates, however as far as I can see there's no way for a server to decide whether a client supports AIA. All of these technologies seem to try to tackle the same problem: reduce the burden of transmitting certificates. I wonder if there should be more a big picture discussion here. If clients have a good way of caching certificates - would that mean transmitting them is so rare that compressing becomes unnecessary? Also regarding 7924: I tried to find out what server and client software supports that. I didn't find anything. One could see that as an indication that it's not a big deal after all. If people are concerned about the data wasted by transmitting certificates, I wonder if it wouldn't be a more important issue to implement the already existing tech that's available instead of inventing new tech. --=20 Hanno B=C3=B6ck https://hboeck.de/ mail/jabber: hanno@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 From nobody Tue Jun 6 17:36:51 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3DE4127286; Tue, 6 Jun 2017 17:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 ggMId-_i7mwe; Tue, 6 Jun 2017 17:36:41 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8467C128961; Tue, 6 Jun 2017 17:36:41 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 376AB58C4EC; Wed, 7 Jun 2017 02:36:38 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 19A97B0C207; Wed, 7 Jun 2017 02:36:38 +0200 (CEST) Date: Wed, 7 Jun 2017 02:36:38 +0200 From: Toerless Eckert To: Benjamin Kaduk Cc: "ops-dir@ietf.org" , "" , Benoit Claise , "sec-ads@ietf.org" , "ops-ads@ietf.org" , ops-chairs@ietf.org Message-ID: <20170607003637.GI12522@faui40p.informatik.uni-erlangen.de> References: <4d2f195a-c61b-4abb-9b33-bc36773775cd@cisco.com> <20170602084300.GB12522@faui40p.informatik.uni-erlangen.de> <20170602103151.GC12522@faui40p.informatik.uni-erlangen.de> <20170602132833.GE12522@faui40p.informatik.uni-erlangen.de> <2f5c3b10-0ad0-466a-03ef-495fa6acb7bc@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2f5c3b10-0ad0-466a-03ef-495fa6acb7bc@akamai.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 00:36:44 -0000 So no options in TLS 1.3 that make it possible to see the server cert in the clear ? On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote: > On 06/02/2017 08:28 AM, Toerless Eckert wrote: > > Another candidate use case coming to mind eg: auditing tht is required in many eg: financial > > environments. In the past i have seen even the requirement for the whole data streams to be unencrypted > > for auditing. Maybe that market segment would also be able to get more privacy but maintain a > > relevant level of auditing if the auditing relevant class of information was visible via > > the cert. > > That use case has been extensively discussed (look for the thread > "Industry Concerns about TLS 1.3", also a fair bit of hallway > discussions), and was not seen to provide a compelling argument for any > change in TLS 1.3. There are purely server-side options that should be > able to provide the necessary functionality (crypto details omitted for > now). > > -Ben From nobody Tue Jun 6 18:59:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F1E1129564; Tue, 6 Jun 2017 18:59:36 -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 Bh0zmisR7Ga5; Tue, 6 Jun 2017 18:59:27 -0700 (PDT) Received: from mail-qt0-x242.google.com (mail-qt0-x242.google.com [IPv6:2607:f8b0:400d:c0d::242]) (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 E0403129B02; Tue, 6 Jun 2017 18:59:20 -0700 (PDT) Received: by mail-qt0-x242.google.com with SMTP id o21so23023612qtb.1; Tue, 06 Jun 2017 18:59:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=FhhoYt17/04c3UNPdD2jL0VFP6XvvdjUh7z75iTErGI=; b=cA/Juk2Dnr1w1HI3z2RfVVhN5d+miytkgLdpxYbbgJysj4V6es7CNG+gRIyyIHQKgA DBOUBBYtl+BhGEtowC2APLCYCawbBbLTssjW1i4f2S+Enld/SuQycZZ5lq96YGDe9y08 d8zzwtn1249wRL9sKdenHbk6p4zLznkIOcZoiHHmsuDn7N+UdjryBQYnhnAjpPLg5cMz VOicNRavHmg4/1S+oo3uifFrrzeINp4d6SbLGi2/EXQ4MskSBQyb3WLHCcyeumId+LfE GyABX4pLJNoEnLB8YXvrbu3nuplyeP2YAXO4AIaXUCmvPxDDtXgYnhwvCj9T130qj+vo B/KA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=FhhoYt17/04c3UNPdD2jL0VFP6XvvdjUh7z75iTErGI=; b=Rpf9Fd2h+biwMlaqBWTz4PwAzTJ1SFzd1Kwh9mF7AQPIlD/WACo6HLHbHhk0Bxigqb U9ky05DFFS0ImyznVFdwLDRIUUZOswXVgFEgQ3cjEMjMTwKivTaoY3ZgN91HvCMiYlYZ 6bbASBYPmLRwvxsg2bMkn07RU+OrGkt3sfC53YR5BV+caknNVPR+Tn6BEt6QPduEcyqW 5PNR0O+4cNy5cj2YZjkBN/58iS678xJVx+c/MOVDreJLLHs/DdMRNifvg17hHL7bB0/t EFT+tTHirem2VkhEuH6+yzPHUsVJI7ZUuC1GOnP3kEPRnf0Ip7Vqb2DEE2GmNk7YWJcK FbTw== X-Gm-Message-State: AODbwcAdF8vezuGdbj6V8Z4iFqeRQAmpjcc7LewJS2Hz1jwK5wjGreoT zPB/Mea4g7uRdO8SF4I= X-Received: by 10.237.42.129 with SMTP id t1mr23174680qtd.55.1496800759940; Tue, 06 Jun 2017 18:59:19 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-70-41.phlapa.fios.verizon.net. [71.175.70.41]) by smtp.gmail.com with ESMTPSA id l46sm162595qtb.21.2017.06.06.18.59.18 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 06 Jun 2017 18:59:19 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Tue, 6 Jun 2017 21:59:16 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) Cc: Toerless Eckert , Benjamin Kaduk , "ops-dir@ietf.org" , Benoit Claise , "sec-ads@ietf.org" , "ops-ads@ietf.org" , ops-chairs@ietf.org References: <2f5c3b10-0ad0-466a-03ef-495fa6acb7bc@akamai.com> <20170607003637.GI12522@faui40p.informatik.uni-erlangen.de> In-Reply-To: <20170607003637.GI12522@faui40p.informatik.uni-erlangen.de> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201706062159.17282.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 01:59:36 -0000 Correct; certs are never in the clear. There is no scenario where anything will be unencrypted after the hellos in TLS 1.3+. If you're doing anything with an old system that relies on this, the general advice is to upgrade your old system to not do that anymore. If you're logging traffic from some server(s), log the traffic on those server(s) instead of MitMing. See old threads for more detail. Dave On Tuesday, June 06, 2017 08:36:38 pm Toerless Eckert wrote: > So no options in TLS 1.3 that make it possible to see the server cert in the clear ? > > On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote: > > On 06/02/2017 08:28 AM, Toerless Eckert wrote: > > > Another candidate use case coming to mind eg: auditing tht is required in many eg: financial > > > environments. In the past i have seen even the requirement for the whole data streams to be unencrypted > > > for auditing. Maybe that market segment would also be able to get more privacy but maintain a > > > relevant level of auditing if the auditing relevant class of information was visible via > > > the cert. > > > > That use case has been extensively discussed (look for the thread > > "Industry Concerns about TLS 1.3", also a fair bit of hallway > > discussions), and was not seen to provide a compelling argument for any > > change in TLS 1.3. There are purely server-side options that should be > > able to provide the necessary functionality (crypto details omitted for > > now). From nobody Tue Jun 6 19:53:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08BB129534; Tue, 6 Jun 2017 19:53:38 -0700 (PDT) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 xqVkGLNNnj8j; Tue, 6 Jun 2017 19:53:37 -0700 (PDT) Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C1C12943E; Tue, 6 Jun 2017 19:53:36 -0700 (PDT) Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id F2AEE58C4EC; Wed, 7 Jun 2017 04:53:32 +0200 (CEST) Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id DA52DB0C1A0; Wed, 7 Jun 2017 04:53:32 +0200 (CEST) Date: Wed, 7 Jun 2017 04:53:32 +0200 From: Toerless Eckert To: Dave Garrett Cc: tls@ietf.org, Benjamin Kaduk , "ops-dir@ietf.org" , Benoit Claise , "sec-ads@ietf.org" , "ops-ads@ietf.org" , ops-chairs@ietf.org Message-ID: <20170607025332.GK12522@faui40p.informatik.uni-erlangen.de> References: <2f5c3b10-0ad0-466a-03ef-495fa6acb7bc@akamai.com> <20170607003637.GI12522@faui40p.informatik.uni-erlangen.de> <201706062159.17282.davemgarrett@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201706062159.17282.davemgarrett@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 02:53:39 -0000 Thanks. Just in case anyone is counting I think thats a bad choice that limits the usefulness of 1.3. And it will just cause less security in systems where logging etc. is required than if this was possible by apps to configure. Why can i negotiate a cipher suite without encryption but not disable cert encryption ? The argument you gave could equally be made to not permit a cipher suite without encryption, right ? Cheers Toerless On Tue, Jun 06, 2017 at 09:59:16PM -0400, Dave Garrett wrote: > Correct; certs are never in the clear. There is no scenario where anything will be unencrypted after the hellos in TLS 1.3+. If you're doing anything with an old system that relies on this, the general advice is to upgrade your old system to not do that anymore. If you're logging traffic from some server(s), log the traffic on those server(s) instead of MitMing. See old threads for more detail. > > > Dave > > > On Tuesday, June 06, 2017 08:36:38 pm Toerless Eckert wrote: > > So no options in TLS 1.3 that make it possible to see the server cert in the clear ? > > > > On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote: > > > On 06/02/2017 08:28 AM, Toerless Eckert wrote: > > > > Another candidate use case coming to mind eg: auditing tht is required in many eg: financial > > > > environments. In the past i have seen even the requirement for the whole data streams to be unencrypted > > > > for auditing. Maybe that market segment would also be able to get more privacy but maintain a > > > > relevant level of auditing if the auditing relevant class of information was visible via > > > > the cert. > > > > > > That use case has been extensively discussed (look for the thread > > > "Industry Concerns about TLS 1.3", also a fair bit of hallway > > > discussions), and was not seen to provide a compelling argument for any > > > change in TLS 1.3. There are purely server-side options that should be > > > able to provide the necessary functionality (crypto details omitted for > > > now). -- --- tte@cs.fau.de From nobody Tue Jun 6 20:15:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5EEC129B4B for ; Tue, 6 Jun 2017 20:15:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=0.001] 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 CxJleCGtUh39 for ; Tue, 6 Jun 2017 20:15:32 -0700 (PDT) Received: from mail-yb0-x232.google.com (mail-yb0-x232.google.com [IPv6:2607:f8b0:4002: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 02391129B5D for ; Tue, 6 Jun 2017 20:15:28 -0700 (PDT) Received: by mail-yb0-x232.google.com with SMTP id o9so206530yba.3 for ; Tue, 06 Jun 2017 20:15:27 -0700 (PDT) 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=3Nf+Leba9aVHx8SSm+35niEJrB8pPQpItU0onHo1+hA=; b=PrkwwHUxDrr/GedJlvMmv8xA94dh7nwJ1FiM1dPkeeTOtm54OFdqSnNrgwguRkvUwQ JNH494RSITeRC0JQAlpVOutHHHVvCsd3N/32kLEsmSUF/bynGOb1aXWb36UKhh42EFe0 NOe47ttDpaGtxNr/D3z7esOzHac/kFeBYVn5exarunIyMzDMBmH23OKy1N4gpQ3SHBPU JZ/uhMmBheixh0eQWOU79qyEB5F6pIkpuDSoHxSNT2dbGcI9MnQuCLLiQxk5/rejd9Mv Gg7hAKw2WsTiVDu0U59BLe+z6wPtBthbJsaHT42azqwgcHn0OWQzHAexXRvVjfhkgRh1 xMKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=3Nf+Leba9aVHx8SSm+35niEJrB8pPQpItU0onHo1+hA=; b=t1ydo4mNbepG0KaEfbEjiihiCPNfjZ6Y7gd79sc7wyTI5RkRrsoR1gmlUlFo5N20Oh GVKymO/y2sa0SiUbInOCNq2q6+RJrTjRnQ7Ovg6+gzxNals8HiLv/YLnm4G/whWpcUCk nWO0Gqv9OaBmYv6gaQOmO3PcDOKK60hllDX/99Dc0mgtHHWqAQsfKCbMxcAAPYe7kLSq H3LFdpIHP3hzE0UQkNcYwPfrRe4PzBgg/KhxKy2iRoPRuxjaoKiFk6jCtE+UvdVREkzM UhdxMehMkG/FzKxosnUuxmgCvmbzPXm0ZMC/zNhqrc2ak1A2CUwIa5C/7BBRJU1+wavo ttbQ== X-Gm-Message-State: AODbwcCMZ9+zJ/NacJ7XBHl29iXe9H6jYm/0U1p59YX3Q9hke8QNOAky 6et8jno3kV+FUm4XF+puN1cZD58Ec4i8 X-Received: by 10.37.171.2 with SMTP id u2mr5462190ybi.122.1496805326846; Tue, 06 Jun 2017 20:15:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.4 with HTTP; Tue, 6 Jun 2017 20:14:46 -0700 (PDT) In-Reply-To: <20170607025332.GK12522@faui40p.informatik.uni-erlangen.de> References: <2f5c3b10-0ad0-466a-03ef-495fa6acb7bc@akamai.com> <20170607003637.GI12522@faui40p.informatik.uni-erlangen.de> <201706062159.17282.davemgarrett@gmail.com> <20170607025332.GK12522@faui40p.informatik.uni-erlangen.de> From: Eric Rescorla Date: Wed, 7 Jun 2017 05:14:46 +0200 Message-ID: To: Toerless Eckert Cc: Dave Garrett , "tls@ietf.org" , Benjamin Kaduk , "ops-dir@ietf.org" , Benoit Claise , "sec-ads@ietf.org" , "ops-ads@ietf.org" , ops-chairs@ietf.org Content-Type: multipart/alternative; boundary="94eb2c063de6ce449505515625b2" Archived-At: Subject: Re: [TLS] Encrypted SNI X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 03:15:34 -0000 --94eb2c063de6ce449505515625b2 Content-Type: text/plain; charset="UTF-8" On Wed, Jun 7, 2017 at 4:53 AM, Toerless Eckert wrote: > > Thanks. Just in case anyone is counting > I think thats a bad choice that limits the usefulness of 1.3. And it will > just > cause less security in systems where logging etc. is required than if this > was possible by apps to configure. > > Why can i negotiate a cipher suite without encryption but not disable cert > encryption ? > You won't be able to do that in TLS 1.3 either. We've removed all the non-encryption cipher suites (though someone could define more off the Standards Track). However, with that said, I don't think that this is a very good analogy. Having unencrypted certs even as an options would significantly impact the state machine, whereas null ciphers do not -Ekr > The argument you gave could equally be made to not permit a cipher suite > without encryption, > right ? > > Cheers > Toerless > > On Tue, Jun 06, 2017 at 09:59:16PM -0400, Dave Garrett wrote: > > Correct; certs are never in the clear. There is no scenario where > anything will be unencrypted after the hellos in TLS 1.3+. If you're doing > anything with an old system that relies on this, the general advice is to > upgrade your old system to not do that anymore. If you're logging traffic > from some server(s), log the traffic on those server(s) instead of MitMing. > See old threads for more detail. > > > > > > Dave > > > > > > On Tuesday, June 06, 2017 08:36:38 pm Toerless Eckert wrote: > > > So no options in TLS 1.3 that make it possible to see the server cert > in the clear ? > > > > > > On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote: > > > > On 06/02/2017 08:28 AM, Toerless Eckert wrote: > > > > > Another candidate use case coming to mind eg: auditing tht is > required in many eg: financial > > > > > environments. In the past i have seen even the requirement for the > whole data streams to be unencrypted > > > > > for auditing. Maybe that market segment would also be able to get > more privacy but maintain a > > > > > relevant level of auditing if the auditing relevant class of > information was visible via > > > > > the cert. > > > > > > > > That use case has been extensively discussed (look for the thread > > > > "Industry Concerns about TLS 1.3", also a fair bit of hallway > > > > discussions), and was not seen to provide a compelling argument for > any > > > > change in TLS 1.3. There are purely server-side options that should > be > > > > able to provide the necessary functionality (crypto details omitted > for > > > > now). > > -- > --- > tte@cs.fau.de > --94eb2c063de6ce449505515625b2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 7, 2017 at 4:53 AM, Toerless Eckert <<= a href=3D"mailto:tte@cs.fau.de" target=3D"_blank">tte@cs.fau.de> wrote:

Thanks. Just in case anyone is counting
I think thats a bad choice that limits the usefulness of 1.3. And it will j= ust
cause less security in systems where logging etc. is required than if this<= br> was possible by apps to configure.

Why can i negotiate a cipher suite without encryption but not disable cert = encryption ?

You won't be able to d= o that in TLS 1.3 either. We've removed all the non-encryption
cipher suites (though someone could define more off the Standards Track).=

However, with that said, I don't think that t= his is a very good analogy. Having
unencrypted certs even as an o= ptions would significantly impact the state machine,
whereas null= ciphers do not

-Ekr


=
=C2=A0
The argument you gave could equally be made to not permit a cipher suite wi= thout encryption,
right ?


Cheers
=C2=A0 =C2=A0 Toerless

On Tue, Jun 06, 2017 at 09:59:16PM -0400, Dave Garrett wrote:
> Correct; certs are never in the clear. There is no scenario where anyt= hing will be unencrypted after the hellos in TLS 1.3+. If you're doing = anything with an old system that relies on this, the general advice is to u= pgrade your old system to not do that anymore. If you're logging traffi= c from some server(s), log the traffic on those server(s) instead of MitMin= g. See old threads for more detail.
>
>
> Dave
>
>
> On Tuesday, June 06, 2017 08:36:38 pm Toerless Eckert wrote:
> > So no options in TLS 1.3 that make it possible to see the server = cert in the clear ?
> >
> > On Sun, Jun 04, 2017 at 03:25:46PM -0500, Benjamin Kaduk wrote: > > > On 06/02/2017 08:28 AM, Toerless Eckert wrote:
> > > > Another candidate use case coming to mind eg: auditing = tht is required in many eg: financial
> > > > environments. In the past i have seen even the requirem= ent for the whole data streams to be unencrypted
> > > > for auditing. Maybe that market segment would also be a= ble to get more privacy but maintain a
> > > > relevant level of auditing if the auditing relevant cla= ss of information was visible via
> > > > the cert.
> > >
> > > That use case has been extensively discussed (look for the t= hread
> > > "Industry Concerns about TLS 1.3", also a fair bit= of hallway
> > > discussions), and was not seen to provide a compelling argum= ent for any
> > > change in TLS 1.3.=C2=A0 There are purely server-side option= s that should be
> > > able to provide the necessary functionality (crypto details = omitted for
> > > now).

--
---
tte@cs.fau.de

--94eb2c063de6ce449505515625b2-- From nobody Tue Jun 6 22:39:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1CBA12E049; Tue, 6 Jun 2017 22:39:14 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FkiW9vZ-zV7q; Tue, 6 Jun 2017 22:39:12 -0700 (PDT) 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 811AD12E03E; Tue, 6 Jun 2017 22:39:11 -0700 (PDT) Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DIA71067; Wed, 07 Jun 2017 05:39:09 +0000 (GMT) Received: from BLREML407-HUB.china.huawei.com (10.20.4.45) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 7 Jun 2017 06:39:08 +0100 Received: from BLREML509-MBS.china.huawei.com ([169.254.8.188]) by BLREML407-HUB.china.huawei.com ([10.20.4.45]) with mapi id 14.03.0301.000; Wed, 7 Jun 2017 11:09:00 +0530 From: Raja ashok To: "draft-ghedini-tls-certificate-compression@ietf.org" CC: "" Thread-Topic: [TLS] adopted: draft-ghedini-tls-certificate-compression Thread-Index: AQHS3pVh0sS3Mj9T2kOsbGjYQYY0RqIY3/6A Date: Wed, 7 Jun 2017 05:38:59 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.213.121] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020203.5937917E.0010, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.8.188, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 6d08990c561a5463a1cb4e743a8093aa Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 05:39:15 -0000 SGkgVmljdG9yICYgQWxlc3NhbmRybywNCg0KSSBoYXZlIGdvbmUgdGhyb3VnaCB0aGUgZHJhZnQg YW5kIEkgYW0gaGF2aW5nIGEgZG91YnQuIA0KDQo+ICAgVGhlIGV4dGVuc2lvbiBvbmx5IGFmZmVj dHMgdGhlIENlcnRpZmljYXRlIG1lc3NhZ2UgZnJvbSB0aGUgc2VydmVyLg0KPiAgIEl0IGRvZXMg bm90IGNoYW5nZSB0aGUgZm9ybWF0IG9mIHRoZSBDZXJ0aWZpY2F0ZSBtZXNzYWdlIHNlbnQgYnkg dGhlDQo+ICAgY2xpZW50Lg0KDQpUaGlzIGRyYWZ0IHByb3ZpZGVzIGEgbWVjaGFuaXNtIHRvIGNv bXByZXNzIG9ubHkgdGhlIHNlcnZlciBjZXJ0aWZpY2F0ZSBtZXNzYWdlLCBub3QgdGhlIGNsaWVu dCBjZXJ0aWZpY2F0ZSBtZXNzYWdlLiBJIGZlZWwgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIG5v dCBwZXJmb3JtZWQgaW4gSFRUUFMgb2Ygd2ViIGFwcGxpY2F0aW9uLiBCdXQgaW4gYWxsIG90aGVy IGFwcGxpY2F0aW9ucyAoZWcuIFdpcmVsZXNzIHNlbnNvciBuZXR3b3JrKSBjZXJ0aWZpY2F0ZSBi YXNlZCBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgbW9yZSBpbXBvcnRhbnQuIA0KDQpTbyBJIHN1 Z2dlc3Qgd2Ugc2hvdWxkIGNvbnNpZGVyIGNvbXByZXNzaW9uIG9uIGNsaWVudCBjZXJ0aWZpY2F0 ZSBtZXNzYWdlIGFsc28uDQoNCg0KUmVnYXJkcywNCkFzaG9rDQoNCg0KSHVhd2VpIFRlY2hub2xv Z2llcw0KQmFuZ2Fsb3JlLCBJbmRpYQ0KaHR0cDovL3d3dy5odWF3ZWkuY29tIA0KDQrmnKzpgq7k u7blj4rlhbbpmYTku7blkKvmnInljY7kuLrlhazlj7jnmoTkv53lr4bkv6Hmga/vvIzku4XpmZDk uo7lj5HpgIHnu5nkuIrpnaLlnLDlnYDkuK3liJflh7rnmoTkuKrkurrmiJbnvqTnu4TjgILnpoEN CuatouS7u+S9leWFtuS7luS6uuS7peS7u+S9leW9ouW8j+S9v+eUqO+8iOWMheaLrOS9huS4jemZ kOS6juWFqOmDqOaIlumDqOWIhuWcsOazhOmcsuOAgeWkjeWItuOAgeaIluaVo+WPke+8ieacrOmC ruS7tuS4rQ0K55qE5L+h5oGv44CC5aaC5p6c5oKo6ZSZ5pS25LqG5pys6YKu5Lu277yM6K+35oKo 56uL5Y2z55S16K+d5oiW6YKu5Lu26YCa55+l5Y+R5Lu25Lq65bm25Yig6Zmk5pys6YKu5Lu277yB DQpUaGlzIGUtbWFpbCBhbmQgaXRzIGF0dGFjaG1lbnRzIGNvbnRhaW4gY29uZmlkZW50aWFsIGlu Zm9ybWF0aW9uIGZyb20gSFVBV0VJLCB3aGljaCANCmlzIGludGVuZGVkIG9ubHkgZm9yIHRoZSBw ZXJzb24gb3IgZW50aXR5IHdob3NlIGFkZHJlc3MgaXMgbGlzdGVkIGFib3ZlLiBBbnkgdXNlIG9m IHRoZSANCmluZm9ybWF0aW9uIGNvbnRhaW5lZCBoZXJlaW4gaW4gYW55IHdheSAoaW5jbHVkaW5n LCBidXQgbm90IGxpbWl0ZWQgdG8sIHRvdGFsIG9yIHBhcnRpYWwgDQpkaXNjbG9zdXJlLCByZXBy b2R1Y3Rpb24sIG9yIGRpc3NlbWluYXRpb24pIGJ5IHBlcnNvbnMgb3RoZXIgdGhhbiB0aGUgaW50 ZW5kZWQgDQpyZWNpcGllbnQocykgaXMgcHJvaGliaXRlZC4gSWYgeW91IHJlY2VpdmUgdGhpcyBl LW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBieSANCnBob25lIG9yIGVt YWlsIGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgaXQhDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0t LS0tDQpGcm9tOiBUTFMgW21haWx0bzp0bHMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9m IFNlYW4gVHVybmVyDQpTZW50OiAwNiBKdW5lIDIwMTcgMTI6NTANClRvOiA8dGxzQGlldGYub3Jn Pg0KU3ViamVjdDogW1RMU10gYWRvcHRlZDogDQoNCkkgYXBwZWFycyB0aGF0IHdl4oCZdmUgZ290 IGVub3VnaCBjb25zZW5zdXMvaW50ZXJlc3QgdG8gYWRvcHQgZHJhZnQtZ2hlZGluaS10bHMtY2Vy dGlmaWNhdGUtY29tcHJlc3Npb24tMDAgYmFzZWQgb24gdGhlIFdHIHNlc3Npb24gaW4gQ2hpY2Fn byBhbmQgdGhpcyB0aHJlYWQ6DQpodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L3Rscy9VNUFtQTlPZXJEXzl6VEJOV2w3WkJDMy1IT0UNCg0KQXV0aG9ycywNCg0KUGxlYXNlIHN1 Ym1pdCBkcmFmdC1pZXRmLXRscy1jZXJ0aWZpY2F0ZS1jb21wcmVzc2lvbiBhdCB5b3VyIGVhcmxp ZXN0IGNvbnZlbmllbmNlLg0KDQpBbGwsDQoNCknigJl2ZSBlc3RhYmxpc2hlZCBhIEdIIHJlcG8g YXQ6DQpodHRwczovL2dpdGh1Yi5jb20vdGxzd2cvY2VydGlmaWNhdGUtY29tcHJlc3Npb24NClZp Y3RvciBhbmQgQWxlc3NhbmRybyBhcmUgQWRtaW5zIHNvIHRoZXnigJlsbCBiZSBjb3B5aW5nIG92 ZXIgdGhlaXIgcmVwby4NCg0KVGhhbmtzISANCg0KSiZTDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KVExTIG1haWxpbmcgbGlzdA0KVExTQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Rscw0K From nobody Tue Jun 6 23:23:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1285129BEC; Tue, 6 Jun 2017 23:23:23 -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 Jcq4A9XVSzAO; Tue, 6 Jun 2017 23:23:22 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::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 22DAF129B63; Tue, 6 Jun 2017 23:23:22 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id a199so1226203qkb.2; Tue, 06 Jun 2017 23:23:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=FTe5BJuUecpUf2Kz+7MCKgx3Xyo6el3Ib1whez8KNCo=; b=r5ErjJ9zNpvjDgedaIQ6cnDUyAFJJsNIC21s7/ygJTpbEaTJKQVDNOrpW/Tn+CYM3e jqVqN8yO5r7O3XbhKVlwB5e1+BzScE2nzS5a9zB85AQEs7YPcM++F2NmDKdxraiXeSnW dw4pIdf3WW+Y2ulmZ9vXjh6Ro7EsW3VWeVlE1YGkN5TsrGzJqr7l0+xzg5Jo3Aqv7ow6 IIiAIwQObVIZ0L6a3Q9emLYQ0BPnaUaTTIk+2Fcl+R61wuJuJpqqagVMNi57dibpQE8u 8SeQ5Hh6ZL2OCzuI+Rzny+OyMac2ACMFy0EJcWX5RDT60Kb1jjuHH8c4hGfEdcc1l+9f AjKg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=FTe5BJuUecpUf2Kz+7MCKgx3Xyo6el3Ib1whez8KNCo=; b=QXbKurDglH24HPKuklxRAaAumh7loffFEzKRk6ciL0r09S8w+K0bjX2mJvzEwfrDEu Aj8eS7K9bYg7bHMB/MW5xQYibwmVMzwIfGgALJ/9qUk0g8tKj7qPO5+sootozWop782t npm9kpu0Cd8l0ZW4CkzHASIYRf43rg57N9q18paQxcVqlmI5h4nK8zmt8rIYQdi6SoBE Hg0hDH6rDR2NNeGdXtFSBRnmRXGJOBFoOa5FcCfzAtl5Z/OnVRjhJtDOKWnIffWUwHlF oOleHU0/gFV4PGABN/LwPxwRwqpXiomy5/nEHCKaECSxe2C3pYoMGYyNdR32hY8fkIDy C3Ww== X-Gm-Message-State: AODbwcBL1iKoL2UP23AUNm+hPsCmv3r8hI/dam73mrUUF2g74mxpmAMV NUQMzpPwDSYRrbQmR6E= X-Received: by 10.55.51.202 with SMTP id z193mr31071390qkz.22.1496816601055; Tue, 06 Jun 2017 23:23:21 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-70-41.phlapa.fios.verizon.net. [71.175.70.41]) by smtp.gmail.com with ESMTPSA id i33sm476735qtb.2.2017.06.06.23.23.20 (version=TLS1 cipher=AES128-SHA bits=128/128); Tue, 06 Jun 2017 23:23:20 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Wed, 7 Jun 2017 02:23:18 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) Cc: Raja ashok , "draft-ghedini-tls-certificate-compression@ietf.org" References: In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201706070223.19120.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 06:23:24 -0000 On Wednesday, June 07, 2017 01:38:59 am Raja ashok wrote: > So I suggest we should consider compression on client certificate message= also. +1 Additionally, there's one bit of the spec which I question the need for: zl= ib support. Unless someone can show a legitimate case where zlib will consi= stently and notably outperform brotli, I don't see the point in defining it= as an option. This is a bran new extension; we don't need backwards compat= ibility here. There's been a general consensus in this WG to avoid algorith= m agility unless there's a real reason for it, so I propose we ditch zlib s= upport and make brotli the default and only specified at the start (promoti= ng it to id 0). Should some problem arise in the future where we actually n= eed to use a decades old compression algorithm, it can be added later. Furt= hermore, we should probably define a pre-defined dictionary for brotli to u= se here which is based on common strings in certificates, rather than its d= efault one for the general web (if such a thing is practical to do here). T= his could boost efficiency here and make it even more worth preferring (als= o likely reducing the size of said dictionary, as the default one is 120kB). Dave From nobody Wed Jun 7 01:27:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4C3812EB0A for ; Wed, 7 Jun 2017 01:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 aFjLOrKrBFWq for ; Wed, 7 Jun 2017 01:26:58 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 2012412EAF7 for ; Wed, 7 Jun 2017 01:26:58 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id t31so3314303ota.1 for ; Wed, 07 Jun 2017 01:26:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=lUz51xdlXTQ7ek8ncn5VDQ2qM5gm+Vn2dgBy27PYrA4=; b=Kw/EAXL9iHIOxNQKfiD7CCA2ZnCiI1jfQwGMdcB/lrXZsrnwxJC6iF52Pg5BBa5AI1 0erXgp+2fIuiT8Z+1Q07IynlN8NjMglezw0Z7don/JUDRDwy3dubhRZ1EAoflLFs3lcK wZPd2t5TKp2AbdInPta+B8HalGRAKpTFOeujrjwsUAs+8Yq1tMY3lKsnsr2yEfevOsKO TUwQeUDthBMrLzb1RWox2aW3/+D7fc1sGCBw8XqmIzsgBIs7pLZ8tezku9jMPDvDsgwm tYW/7RYiL9uXUN8TVhXgomadeJWbWOxqGyaHTDVX9SUjmdVwlHE5y6XLjRg1uWMlzD4H k+Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=lUz51xdlXTQ7ek8ncn5VDQ2qM5gm+Vn2dgBy27PYrA4=; b=nJS6fM6ypaVCdX8A+ZaqXvE2hzuqmP6dQbOrapFK5U/y1wuKk+JU0qnOmdBdope+cW rF+rs13D/bw3lQeVqHjmBpVhbsILW+g+MQMk1ciYX6e7hiBmOKw9Ltai5LPnXZUC0l88 uoWcujzNglEq7U2Y9iDWh8YtXqt06armzvspIK+/RVHaOEzMfbu6+rYIGSShZSe7q2Ji XsrZA7iYyKiGzt63z7hUC3hu2VgJaaimZ8JjTzGYdQMWnPK6x9zVOL9bSUH/epjPDr4k ApMKoI3DCYcKiTlJsp32prcPUWbu/VHU3dIQX4YKh6WFvc69mZFLbyVfhDev9uA4yy3N DlfQ== X-Gm-Message-State: AODbwcCdDTxBTlhH6ZJTW6ERvCS8QyXvcwSLSvNOUSQW/BAEBjFT61gn Pv/7HVESnBkeGyOarU+8Y+mr8Yv2HxsV X-Received: by 10.157.37.45 with SMTP id k42mr19735331otb.83.1496824017436; Wed, 07 Jun 2017 01:26:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.88.16 with HTTP; Wed, 7 Jun 2017 01:26:56 -0700 (PDT) In-Reply-To: References: From: Sankalp Bagaria Date: Wed, 7 Jun 2017 13:56:56 +0530 Message-ID: To: tls@ietf.org, "Hanno B?ck" Cc: sankalp , Balaji Rajendran Content-Type: multipart/alternative; boundary="001a11352e46d9c50c05515a7f4f" Archived-At: Subject: Re: [TLS] TLS Digest, Vol 155, Issue 13 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 08:27:01 -0000 --001a11352e46d9c50c05515a7f4f Content-Type: text/plain; charset="UTF-8" > > > Message: 3 > Date: Tue, 6 Jun 2017 16:23:24 +0200 > From: Hanno B?ck > To: tls@ietf.org > Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression > Message-ID: <20170606162324.4aee493b@pc1> > Content-Type: text/plain; charset=UTF-8 > > On Tue, 6 Jun 2017 09:20:03 +0200 > Sean Turner wrote: > > > I appears that we?ve got enough consensus/interest to adopt > > draft-ghedini-tls-certificate-compression-00 based on the WG session > > in Chicago and this thread: > > Hi, > > one aspects brought up in that thread was that there is already RFC > 7924, which allows certificate caching. There's also AIA, which allows > a client to fetch intermediate certificates, however as far as I can > see there's no way for a server to decide whether a client supports AIA. > > All of these technologies seem to try to tackle the same problem: > reduce the burden of transmitting certificates. > > I wonder if there should be more a big picture discussion here. If > clients have a good way of caching certificates - would that mean > transmitting them is so rare that compressing becomes unnecessary? > > Also regarding 7924: I tried to find out what server and client software > supports that. I didn't find anything. One could see that as an > indication that it's not a big deal after all. If people are concerned > about the data wasted by transmitting certificates, I wonder if it > wouldn't be a more important issue to implement the already existing > tech that's available instead of inventing new tech. > > > -- > Hanno B?ck > https://hboeck.de/ > Dear Hanno, This issue was raised by me also on April 5, 2017. I got the following reply. Regards, Sankalp Bagaria. On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria wrote: > Hello, > > How is Certificate Compression advantageous over tls cached-info > extension? > Only case I can think of is - when the certificate is being sent for the > first time, > it can be compressed. Since the client doesn't have a copy of the > certificate, > cached-info can't be used. Are there more cases where compression is > useful? > Does cached-info not represent a privacy info-leak by disclosing past sessions prior to authenticating the new session? Versus compression, which limits it to the session and thus reveals no new/additional information. That was certainly true for TLS1.2 Is compression not a simpler implementation - given the 'two' hard problems of computer science (caching, naming, off-by-one)? For example, you'd need to maintain a per-host cache of certificateinformation to meaningfully make use of it (... or else you end up with cross-origin state leakage, at least in the context of a browser, which is a Bad Thing). You would either need to read that information from stable storage prior to making the connection (so that you can negotiate the cached info), or you'd need to do a lazy-path where you index the cached entries and send those as available to the server, while in parallel beginning to load those entries. If those entries are corrupted, but used in the connection, the connection will fail. If those entries are removed during the connection establishment, the connection will fail. In short, cached-info represents a much greater degree of complexity and questionable privacy (both cross-origin and same origin - again, something relevant for browsers, but perhaps not relevant for others). Let's keep it simple :) --001a11352e46d9c50c05515a7f4f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=


Message: 3
Date: Tue, 6 Jun 2017 16:23:24 +0200
From: Hanno B?ck <hanno@hboeck.de= >
To: tls@ietf.org
Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression<= br> Message-ID: <20170606162324.4aee493b@pc1>
Content-Type: text/plain; charset=3DUTF-8

On Tue, 6 Jun 2017 09:20:03 +0200
Sean Turner <sean@sn3rd.com> wr= ote:

> I appears that we?ve got enough consensus/interest to adopt
> draft-ghedini-tls-certificate-compression-00 based on the WG sess= ion
> in Chicago and this thread:

Hi,

one aspects brought up in that thread was that there is already RFC
7924, which allows certificate caching. There's also AIA, which allows<= br> a client to fetch intermediate certificates, however as far as I can
see there's no way for a server to decide whether a client supports AIA= .

All of these technologies seem to try to tackle the same problem:
reduce the burden of transmitting certificates.

I wonder if there should be more a big picture discussion here. If
clients have a good way of caching certificates - would that mean
transmitting them is so rare that compressing becomes unnecessary?

Also regarding 7924: I tried to find out what server and client software supports that. I didn't find anything. One could see that as an
indication that it's not a big deal after all. If people are concerned<= br> about the data wasted by transmitting certificates, I wonder if it
wouldn't be a more important issue to implement the already existing tech that's available instead of inventing new tech.


--
Hanno B?ck
https:/= /hboeck.de/

Dear Hanno,
<= br>
This issue was raised by me also on April 5, 2017. I got the = following reply.

Regards,
Sankalp Bagari= a.

= On Wed, Apr 5, 2017 at 1:35 AM, Sankalp Bagaria=C2=A0<= sankalp@cdac.in>= ;=C2=A0wrote:
<= u>
Hello,
=C2=A0
How is=C2=A0Certificate=C2=A0Compression<= /span>=C2=A0advantageous over=C2=A0tls=C2= =A0cached-info extension?
Only case I can think of is - when the= =C2=A0certificate=C2=A0is being sent for th= e first time,
it can be compressed. Since the client doesn't = have a copy of the=C2=A0certificate,
<= div>cached-info can't be used. Are there more cases where=C2=A0compression=C2=A0is useful?

Does cached-info not= represent a privacy info-leak by disclosing past sessions prior to authent= icating the new session? Versus=C2=A0compression, which limits it to the session and thus reveals no new/additional in= formation. That was certainly true for TLS1.2

Is=C2=A0compression=C2=A0not a simpler implementation - given the &#= 39;two' hard problems of computer science (caching, naming, off-by-one)= ? For example, you'd need to maintain a per-host cache of=C2=A0certificateinformation to meaningfully make use of = it (... or else you end up with cross-origin state leakage, at least in the= context of a browser, which is a Bad Thing). You would either need to read= that information from stable storage prior to making the connection (so th= at you can negotiate the cached info), or you'd need to do a lazy-path = where you index the cached entries and send those as available to the serve= r, while in parallel beginning to load those entries. If those entries are = corrupted, but used in the connection, the connection will fail. If those e= ntries are removed during the connection establishment, the connection will= fail.

In short, cached-info represents a much greater degree of = complexity and questionable privacy (both cross-origin and same origin - ag= ain, something relevant for browsers, but perhaps not relevant for others).= Let's keep it simple :)=C2=A0
--001a11352e46d9c50c05515a7f4f-- From nobody Wed Jun 7 04:04:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5C4012942F for ; Wed, 7 Jun 2017 04:03:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RP_MATCHES_RCVD=-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=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 PvYaJVOOjoYx for ; Wed, 7 Jun 2017 04:03:57 -0700 (PDT) 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 022E4126FB3 for ; Wed, 7 Jun 2017 04:03:56 -0700 (PDT) Received: by mail-ua0-x231.google.com with SMTP id x47so4237241uab.0 for ; Wed, 07 Jun 2017 04:03:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=0uzQUa7Kjdcj6u/SO5lfRrZQBN+9eiVIlupqWOG1VtE=; b=K0rA7iHL50fTAcF/lJrmLQmuxdd8jdPlygeI4Kt/X7ogBht/FOvb1nnxe8TEDIzB45 pmMdowaWghaFc1bzDD5lfqG+3VSWcY5M9eRZQ4yM6Lj4VRbAMAMngxb+AFhGFC99k1xn h9+5t8nR3nNqsXUP3As8ZGv/JNQLor8yA0cSwI4BOKiTxWNOYbdX2i5/7ze8R+V2f7QZ cFsI0bjupgP8hCSEVQW6X56J3iZeE/fM/wHVsr4NHh39040k4jp04frj6gCO9bGRTZlv 3xQ1MWOpUFx0GFd3neGRHULcqFMt8WDTJPsuOzhIWbDzrWGM96vexAVXX/4e28+TXveB FK+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=0uzQUa7Kjdcj6u/SO5lfRrZQBN+9eiVIlupqWOG1VtE=; b=E4m6UH+ZHUWZHI+Ph9g8XpRKBd9W5AikiCBqitYpceNbv+x2ZREpr/ut0Q+oeGAZW/ TWe8rG5vyd6qpVYqQ72A/rDY5sudRvCv/AAe/KaJ2JOkhdhzNVrImUJbVGwus3Rr6xjN 0057D2KYSDi0Gl0fiZfsQmyFsp5ri36FQG8gGleWUE8iN0xlFqp/sAv/MWp6Fz/1aUwu nh2di9MBoqDaKuNryBbzlzNBF3dMJZ7gZB2AU4kNZqdZpT4RX6UNhdBLoBmiyI5CfPkO 4mKGfVpkhV7gJ4Wz3iBAGPFggOPbOyQXqbjigCypTPOpRkay3pp7RZexD3SmYvqk2/Gx q6Jw== X-Gm-Message-State: AODbwcAot+IgNBu5ZgiznMR+i3GJdkp5cc9I7jQeJyaw9xsmfnTNAb9F liFAFQF0dp1aL0luaEoh6oMSvGLtCB45 X-Received: by 10.159.60.82 with SMTP id w18mr15058802uah.19.1496833435797; Wed, 07 Jun 2017 04:03:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.153.131 with HTTP; Wed, 7 Jun 2017 04:03:55 -0700 (PDT) In-Reply-To: <201706070223.19120.davemgarrett@gmail.com> References: <201706070223.19120.davemgarrett@gmail.com> From: Piotr Sikora Date: Wed, 7 Jun 2017 04:03:55 -0700 Message-ID: To: Dave Garrett Cc: tls@ietf.org, "draft-ghedini-tls-certificate-compression@ietf.org" , Alessandro Ghedini , Victor Vasiliev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 11:03:59 -0000 Hey Dave, > Additionally, there's one bit of the spec which I question the need for: = zlib support. Unless someone can show a legitimate case where zlib will con= sistently and notably outperform brotli, I don't see the point in defining = it as an option. This is a bran new extension; we don't need backwards comp= atibility here. There's been a general consensus in this WG to avoid algori= thm agility unless there's a real reason for it, so I propose we ditch zlib= support and make brotli the default and only specified at the start (promo= ting it to id 0). Should some problem arise in the future where we actually= need to use a decades old compression algorithm, it can be added later. Fu= rthermore, we should probably define a pre-defined dictionary for brotli to= use here which is based on common strings in certificates, rather than its= default one for the general web (if such a thing is practical to do here).= This could boost efficiency here and make it even more worth preferring (a= lso likely reducing the size of said dictionary, as the default one is 120k= B). To play devil's advocate, why do suggest we ditch zlib and not Brotli? I just did an experiment using certificate chains for facebook.com (ECDSA) and google.com (RSA). I compressed them with Brotli (at levels: 1, 6, 9 and 11 - aka Z) and gzip (at levels: 1, 6 and 9): facebook.com-ecdsa-chain.pem 4485 (222%) facebook.com-ecdsa-chain.der 2024 (100%) facebook.com-ecdsa-chain.br1 1823 (90%) facebook.com-ecdsa-chain.br6 1673 (83%) facebook.com-ecdsa-chain.br9 1644 (81%) facebook.com-ecdsa-chain.brZ 1597 (79%) facebook.com-ecdsa-chain.gz1 1699 (84%) facebook.com-ecdsa-chain.gz6 1687 (83%) facebook.com-ecdsa-chain.gz9 1687 (83%) google.com-rsa-chain.pem 5749 (266%) google.com-rsa-chain.der 2160 (100%) google.com-rsa-chain.br1 1541 (71%) google.com-rsa-chain.br6 1343 (62%) google.com-rsa-chain.br9 1348 (62%) google.com-rsa-chain.brZ 1330 (62%) google.com-rsa-chain.gz1 1434 (66%) google.com-rsa-chain.gz6 1398 (65%) google.com-rsa-chain.gz9 1398 (65%) Then, I did the same using pre-defined dictionary from QUIC Crypto: facebook.com-ecdsa-chain.bq1 1823 (90%) facebook.com-ecdsa-chain.bq6 1505 (74%) facebook.com-ecdsa-chain.bq9 1482 (73%) facebook.com-ecdsa-chain.bqZ 1460 (72%) facebook.com-ecdsa-chain.gq1 1536 (76%) facebook.com-ecdsa-chain.gq6 1506 (74%) facebook.com-ecdsa-chain.gq9 1506 (74%) google.com-rsa-chain.bq1 1541 (71%) google.com-rsa-chain.bq6 1248 (58%) google.com-rsa-chain.bq9 1239 (57%) google.com-rsa-chain.bqZ 1233 (57%) google.com-rsa-chain.gq1 1317 (61%) google.com-rsa-chain.gq6 1266 (59%) google.com-rsa-chain.gq9 1266 (59%) As you can see, at level 1, Brotli is easily outperformed by gzip with and without dictionary, at level 6, both are basically the same, and at level 9/Z, Brotli wins by a small margin in terms of file size. However, you need to keep in mind that Brotli has significantly higher cost of compression, both in terms of CPU and memory allocations (>40MB at higher levels), which might be unacceptable in some environments. Don't get me wrong, I'm a big fan of Brotli, but unless we want to squeeze every single byte out of the compression and/or use pre-compressed certificates, then maybe Brotli isn't the best and only choice here? Best regards, Piotr Sikora From nobody Wed Jun 7 06:36:25 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6131A12EC22; Wed, 7 Jun 2017 06:36:18 -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, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 CcYBlmyGXNZX; Wed, 7 Jun 2017 06:36:16 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 B9DBA12EB0C; Wed, 7 Jun 2017 06:36:16 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v57DVmjd015773; Wed, 7 Jun 2017 14:36:12 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=3Y6SVJv6QRPbsfRo6jwztoxVcCOD4BjDfCzvNQgDbEU=; b=pAUHgQaoV95NWi5V2qSThOr5wxIQFhIbS7wK9X4qJ9U39DsaXD1yKlT4dMLcuBqvtRN+ v8+UoVQ/zLe7w3IwUAyHwceTqigJ+B/qbljeCxAadAViaWp3UhhxxqOGviFrSI7okNYH XHnhko8dWAa/dU9Y23u+x1Imt1dOuERR9MjmLzf/fjDtxBc2B4hfDx5UmFbN9UZLch0H FtWJJFGvAgw0KpnPer2dWcLPQ22Y5h/ghyjkhKfwXDUbT5j1RrGWN6DYRml62Co0+QX6 WHnTUjXg8UkrC4YYtxF+NcJCHNUnH0SowviiCu+bdFK8CnnZJj43wlhAU1RERxt7uQsf 1w== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2ax5fx3ewg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Jun 2017 14:36:12 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v57DUhIE011926; Wed, 7 Jun 2017 09:36:11 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 2aurev67tw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Jun 2017 09:36:11 -0400 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.1263.5; Wed, 7 Jun 2017 09:36:10 -0400 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.1263.000; Wed, 7 Jun 2017 09:36:10 -0400 From: "Salz, Rich" To: Dave Garrett , "tls@ietf.org" CC: "draft-ghedini-tls-certificate-compression@ietf.org" Thread-Topic: [TLS] adopted: draft-ghedini-tls-certificate-compression Thread-Index: AQHS31Bsycpqly8XtUyjr7D2I2Y2Z6IZMYgAgAA1aJA= Date: Wed, 7 Jun 2017 13:36:10 +0000 Message-ID: <103fac569dda4d208015d42826f83316@usma1ex-dag1mb1.msg.corp.akamai.com> References: <201706070223.19120.davemgarrett@gmail.com> In-Reply-To: <201706070223.19120.davemgarrett@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.40.78] Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706070251 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-07_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706070251 Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 13:36:18 -0000 -- =20 Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz@jabber.at Twitter: RichSalz > Unless someone can show a legitimate case where zlib will > consistently and notably outperform brotli, I don't see the point in defi= ning it > as an option. As long as the protocol includes space for the encryption algorithm, I agre= e. > Furthermore, we should probably define a pre-defined dictionary for > brotli to use here which is based on common strings in certificates, rath= er That could mean that "brotli" is really "brotli+dictionary FOO" which seems= like a good idea. From nobody Wed Jun 7 13:29:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC84129B38; Wed, 7 Jun 2017 13:28:59 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 AjK6yoZjz03v; Wed, 7 Jun 2017 13:28:57 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id DC291129AC7; Wed, 7 Jun 2017 13:28:55 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id EE08A63245; Wed, 7 Jun 2017 23:28:52 +0300 (EEST) 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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id Z0oORFhMeoJO; Wed, 7 Jun 2017 23:28:52 +0300 (EEST) 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 AACE0C4; Wed, 7 Jun 2017 23:28:52 +0300 (EEST) Date: Wed, 7 Jun 2017 23:28:48 +0300 From: Ilari Liusvaara To: Raja ashok Cc: "draft-ghedini-tls-certificate-compression@ietf.org" , "" Message-ID: <20170607202848.GA21563@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: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 20:28:59 -0000 On Wed, Jun 07, 2017 at 05:38:59AM +0000, Raja ashok wrote: > Hi Victor & Alessandro, > > I have gone through the draft and I am having a doubt. > > > The extension only affects the Certificate message from the server. > > It does not change the format of the Certificate message sent by the > > client. > > This draft provides a mechanism to compress only the server certificate > message, not the client certificate message. I feel client authentication > is not performed in HTTPS of web application. But in all other applications > (eg. Wireless sensor network) certificate based client authentication is > more important. > > So I suggest we should consider compression on client certificate message > also. Doing client certificate compression would add some complexity, because the compression indication currently needs to be external to certificates, and there is no place to stick such indication for client certificate. -Ilari From nobody Wed Jun 7 13:45:06 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111D9131491 for ; Wed, 7 Jun 2017 13:45:01 -0700 (PDT) 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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 cgBvMRv_fvYk for ; Wed, 7 Jun 2017 13:44:57 -0700 (PDT) Received: from mail-pg0-x22a.google.com (mail-pg0-x22a.google.com [IPv6:2607:f8b0:400e: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 863F6131486 for ; Wed, 7 Jun 2017 13:44:55 -0700 (PDT) Received: by mail-pg0-x22a.google.com with SMTP id k71so8939407pgd.2 for ; Wed, 07 Jun 2017 13:44:55 -0700 (PDT) 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=F1xE5eyUNzejO0vjWuMyED1mCugPPvK87kyIGP7sSo8=; b=YRclrpbo5A0HfBL6zC30G+hfSBrlxSaN9dOfFgXMmxfWSvpEPzxi4qEaeePjdzlZ85 lvJcV9QAvC9T6A///0P6DJ6GAFflwb+DSOpfcmmXWmz0r0m5lqETqD/GvDIe9RROR6GV VKA0zjbNrY7DcXVvQTV1nSRHS7VT8STahVRnE= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=F1xE5eyUNzejO0vjWuMyED1mCugPPvK87kyIGP7sSo8=; b=H1r83UraWTDFxK+KH9qe2broGpwOsIQjCrWmxvFwFF3t/WQbwML9wox/taH55jaOTX wjP/Udo1yvwlBXBYqkKrLmpWnZqQ0oslA2m1cyiYXNf0y/nrdBZCEA8IneDff8Mk+QR/ lKZyitI9t29O2KQItIkJeyeRG5PKxUPC6/k0Tgt+6fF/zNy4UfASHfvOvD+iC6z8wMN+ q7n2fJka9lax37KNK9pK0FIHlcVts0QJlbzdkS7Dq5W/p+aXjGePCJtI9VgSQ6oaREDS Sy6iGa1H3Qn1f0RMKDQn7lCz/py8ExMZe8hPCkBYBhUysh/U6hlGD5GKNGIx4ifWO2as W+3g== X-Gm-Message-State: AODbwcB2AYoCZCcv+ZrHWq6JzWQmsLJnmKYmDK4AzZqtVJBTY1ior6er An1Q1Ow1dpWYi3UHji6+N3RC78twFEAT X-Received: by 10.98.33.84 with SMTP id h81mr32679651pfh.81.1496868295075; Wed, 07 Jun 2017 13:44:55 -0700 (PDT) MIME-Version: 1.0 References: <20170607202848.GA21563@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170607202848.GA21563@LK-Perkele-V2.elisa-laajakaista.fi> From: David Benjamin Date: Wed, 07 Jun 2017 20:44:43 +0000 Message-ID: To: Ilari Liusvaara , Raja ashok Cc: "draft-ghedini-tls-certificate-compression@ietf.org" , "" Content-Type: multipart/alternative; boundary="001a113df29c015f4e055164cfae" Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 20:45:01 -0000 --001a113df29c015f4e055164cfae Content-Type: text/plain; charset="UTF-8" On Wed, Jun 7, 2017 at 4:29 PM Ilari Liusvaara wrote: > On Wed, Jun 07, 2017 at 05:38:59AM +0000, Raja ashok wrote: > > Hi Victor & Alessandro, > > > > I have gone through the draft and I am having a doubt. > > > > > The extension only affects the Certificate message from the server. > > > It does not change the format of the Certificate message sent by the > > > client. > > > > This draft provides a mechanism to compress only the server certificate > > message, not the client certificate message. I feel client authentication > > is not performed in HTTPS of web application. But in all other > applications > > (eg. Wireless sensor network) certificate based client authentication is > > more important. > > > > So I suggest we should consider compression on client certificate message > > also. > > Doing client certificate compression would add some complexity, because > the compression indication currently needs to be external to certificates, > and there is no place to stick such indication for client certificate. > There was a proposal somewhere to: - Rename Certificate to CompressedCertificate. - Allocate a new HandshakeType.compressed_certificate, with contents CompressedCertificate. - If the client (respectively, server) sends the extension in the ClientHello (respectively, CertificateRequest), the server (respectively, client) is allowed to send a CompressedCertificate message instead of Certificate. The client (respectively, server) dispatches on the message type when processing. This is a little unusual of an extension acknowledgement and conflicts with, say, another extension which tries to play the same game. (Though the existing scheme needs to be outermost too since it swaps out the spelling of the CompressedCertificate message.) David --001a113df29c015f4e055164cfae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 7,= 2017 at 4:29 PM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Wed, Jun 07, 2017 at 05:38:59AM +0000, Raja ashok wrote:
> Hi Victor & Alessandro,
>
> I have gone through the draft and I am having a doubt.
>
> >=C2=A0 =C2=A0The extension only affects the Certificate message fr= om the server.
> >=C2=A0 =C2=A0It does not change the format of the Certificate mess= age sent by the
> >=C2=A0 =C2=A0client.
>
> This draft provides a mechanism to compress only the server certificat= e
> message, not the client certificate message. I feel client authenticat= ion
> is not performed in HTTPS of web application. But in all other applica= tions
> (eg. Wireless sensor network) certificate based client authentication = is
> more important.
>
> So I suggest we should consider compression on client certificate mess= age
> also.

Doing client certificate compression would add some complexity, because
the compression indication currently needs to be external to certificates,<= br> and there is no place to stick such indication for client certificate.
<= /blockquote>

There was a proposal somewhere to:

- =C2=A0Rename Certificate to CompressedCertificate.
=

- Allocate a new=C2=A0HandshakeType.compressed_certific= ate, with contents=C2=A0CompressedCertificate.

- If the client (respectively, server) sends the extension in the ClientHe= llo (respectively,=C2=A0CertificateRequest), the server (respectively, clie= nt) is allowed to send a CompressedCertificate message instead of Certifica= te. The=C2=A0client (respectively, server) dispatches on the message type w= hen processing.

This is a little unusual of an= extension acknowledgement and conflicts with, say, another extension which= tries to play the same game. (Though the existing scheme needs to be outer= most too since it swaps out the spelling of the CompressedCertificate messa= ge.)

David
--001a113df29c015f4e055164cfae-- From nobody Wed Jun 7 13:51:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2214A1252BA; Wed, 7 Jun 2017 13:51:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 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, 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 5BSZMXeajOIP; Wed, 7 Jun 2017 13:51:00 -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 C7195124BE8; Wed, 7 Jun 2017 13:50:59 -0700 (PDT) Received: from mail08.wdf.sap.corp (mail01.sap.corp [194.39.131.53]) (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 3wjggj3gHWz1J9C; Wed, 7 Jun 2017 22:50:57 +0200 (CEST) X-purgate-ID: 152705::1496868657-00000816-66E2A85C/0/0 X-purgate-size: 1415 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 mail08.wdf.sap.corp (Postfix) with ESMTP id 3wjggh6nMwz2xdT; Wed, 7 Jun 2017 22:50:56 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id E3A4D1A662; Wed, 7 Jun 2017 22:50:56 +0200 (CEST) In-Reply-To: <20170607202848.GA21563@LK-Perkele-V2.elisa-laajakaista.fi> To: Ilari Liusvaara Date: Wed, 7 Jun 2017 22:50:56 +0200 (CEST) CC: Raja ashok , "draft-ghedini-tls-certificate-compression@ietf.org" , "" Reply-To: mrex@sap.com 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: <20170607205056.E3A4D1A662@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 07 Jun 2017 20:51:02 -0000 Ilari Liusvaara wrote: >On Wed, Jun 07, 2017 at 05:38:59AM +0000, Raja ashok wrote: >> Hi Victor & Alessandro, >> >> I have gone through the draft and I am having a doubt. >> >>> The extension only affects the Certificate message from the server. >>> It does not change the format of the Certificate message sent by the >>> client. >> >> This draft provides a mechanism to compress only the server certificate >> message, not the client certificate message. I feel client authentication >> is not performed in HTTPS of web application. But in all other applications >> (eg. Wireless sensor network) certificate based client authentication is >> more important. >> >> So I suggest we should consider compression on client certificate message >> also. > > Doing client certificate compression would add some complexity, because > the compression indication currently needs to be external to certificates, > and there is no place to stick such indication for client certificate. A TLS extension could do this indication just fine. ASN.1 DER encoded X.509v3 certificates all have the same first 12 bits. 0x30 0x8* So sending an indication inband should also be possible. But a negotiated TLS extension (proposed by client in ClientHello, confirmed by server in ServerHello) could also change the Certificate PDU to provide room for a seperate indicator. -Martin From nobody Wed Jun 7 17:43:54 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2313E1314B5; Wed, 7 Jun 2017 17:43:53 -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 RAsDjY9-t1_v; Wed, 7 Jun 2017 17:43:42 -0700 (PDT) Received: from mail-qt0-x244.google.com (mail-qt0-x244.google.com [IPv6:2607:f8b0:400d:c0d::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 C25AD1314AE; Wed, 7 Jun 2017 17:43:40 -0700 (PDT) Received: by mail-qt0-x244.google.com with SMTP id w1so4937525qtg.0; Wed, 07 Jun 2017 17:43:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=hxZdujIf73KCCJGbTSG5pWu9uQ8Y+m/jULPmaObCyiQ=; b=r7FzKd/ZyJ4wUhqmJMoveXyZ178J8MOb2Y1glQHXPQKM1FL66MB+Af8Bt2uq7jepJo 1TF+0+bTk19vEsa6/PFP4QhUo/5PMSPP5kAI6jBOaZJx7r4QUIu0PqS6TzwwBRcqKnAP xdFDIWuQwrbB/0b3Tk8ruDO2sEWes2wWUg5+VoZ7fQ7vclpMzakg9VQ73QzpPYgmHTTu 0ur3jgwnxfAqK4cy5Qb/uc4NHAocxbWpOPgIje4rupYFftpjRDEAN+vOWH5Syhud1J8q igNmj1IofVOLYGk67atHzUTRz3v7pyNbtMglkd8Xvutl/qcZJM3I3gKyBNyhNniiG8Vl NvEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=hxZdujIf73KCCJGbTSG5pWu9uQ8Y+m/jULPmaObCyiQ=; b=GvYxsA7J9AxCvHUN5LwIdXUr7QojC9H0aPnxTKNublnTgwBRh/CQIORmzQddiHCsaX KbQ5bk0IzY0ehRYJE+1qKj87Z0Lo3Z+EdePSwr+7gwS4VIoFHbZcRmUAnUbL+fSAPsDs 8Vj4PlHCUDAKbyzZqzpOeAEfPvDLlTWCCedwCfmQydhvVY1gMwezEXrcbWhVK+W6STtC Kfe1f3SDtdZNCb2O9eIL4olksACpiqnmNB5nfbiEd/OT5InPMBfYkHbpw+5Z0+Rv1GLD eq0qcYfCx4y4+vOw040S2O1oul+pCb/MEjOc2aZXOh1dPpqS8YaPlaWOIqqzKQaPkpZm zQxg== X-Gm-Message-State: AODbwcDGgTT3iblVaG1vUGhK3HQia/oNMUWExTR7cUEiWSiM/iMov0Ql luwxdSZ2qXBHkg== X-Received: by 10.200.8.13 with SMTP id u13mr34898180qth.233.1496882619898; Wed, 07 Jun 2017 17:43:39 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-70-41.phlapa.fios.verizon.net. [71.175.70.41]) by smtp.gmail.com with ESMTPSA id h14sm2222169qkh.64.2017.06.07.17.43.38 (version=TLS1 cipher=AES128-SHA bits=128/128); Wed, 07 Jun 2017 17:43:39 -0700 (PDT) From: Dave Garrett To: Piotr Sikora Date: Wed, 7 Jun 2017 20:43:37 -0400 User-Agent: KMail/1.13.5 (Linux/2.6.32-74-generic-pae; KDE/4.4.5; i686; ; ) Cc: tls@ietf.org, "draft-ghedini-tls-certificate-compression@ietf.org" , Alessandro Ghedini , Victor Vasiliev References: <201706070223.19120.davemgarrett@gmail.com> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201706072043.38076.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2017 00:43:53 -0000 On Wednesday, June 07, 2017 07:03:55 am Piotr Sikora wrote: > > Additionally, there's one bit of the spec which I question the need for= : zlib support. Unless someone can show a legitimate case where zlib will c= onsistently and notably outperform brotli, I don't see the point in definin= g it as an option. This is a bran new extension; we don't need backwards co= mpatibility here. There's been a general consensus in this WG to avoid algo= rithm agility unless there's a real reason for it, so I propose we ditch zl= ib support and make brotli the default and only specified at the start (pro= moting it to id 0). Should some problem arise in the future where we actual= ly need to use a decades old compression algorithm, it can be added later. = =46urthermore, we should probably define a pre-defined dictionary for brotl= i to use here which is based on common strings in certificates, rather than= its default one for the general web (if such a thing is practical to do he= re). This could boost efficiency here and make it even more worth preferrin= g (also likely reducing the size of said dictionary, as the default one is = 120kB). >=20 > To play devil's advocate, why do suggest we ditch zlib and not Brotli? >=20 > I just did an experiment using certificate chains for facebook.com > (ECDSA) and google.com (RSA). >=20 [...snip...] >=20 > As you can see, at level 1, Brotli is easily outperformed by gzip with > and without dictionary, at level 6, both are basically the same, and > at level 9/Z, Brotli wins by a small margin in terms of file size. >=20 > However, you need to keep in mind that Brotli has significantly higher > cost of compression, both in terms of CPU and memory allocations > (>40MB at higher levels), which might be unacceptable in some > environments. >=20 > Don't get me wrong, I'm a big fan of Brotli, but unless we want to > squeeze every single byte out of the compression and/or use > pre-compressed certificates, then maybe Brotli isn't the best and only > choice here? This is a convincing argument to me. Thanks for the data. Given this inform= ation, I agree that supporting both algorithms can be helpful here, dependi= ng on server hardware constraints. I'm still curious to know if we can potentially create a lightweight cert-s= pecific dictionary here that can boost things a bit. Or, is the QUIC one la= rgely based on certs too? As to your devil's advocate suggestion: ... yeah, if Brotli doesn't give us= any useful gains here over zlib, even with a new dict, I'd be ok with not = specifying it for use. Your test does show it getting a small win at max co= mpression, so that may not be the case. After fiddling with defining a new = dict, test data against a larger set of certs could be useful. Dave From nobody Wed Jun 7 21:18:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A82B129B09; Wed, 7 Jun 2017 21:18:21 -0700 (PDT) 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 AuU4Ysa1Dl1z; Wed, 7 Jun 2017 21:18:18 -0700 (PDT) Received: from mail-pg0-x236.google.com (mail-pg0-x236.google.com [IPv6:2607:f8b0:400e: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 9443F129B06; Wed, 7 Jun 2017 21:18:18 -0700 (PDT) Received: by mail-pg0-x236.google.com with SMTP id v18so11850626pgb.1; Wed, 07 Jun 2017 21:18:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ch1qkNHLGu6Fx1PsuGU0QmheKQltF8emaYDvwlqcgKo=; b=Xf8bfb4QClpVDirX+23UBU3VR+oMlT2EXX/2jPhIIARF7KpAlHv3xqU0xlwjTZ0gVY oaYSBTs8FB2reQhIFmaWqmXP5gcXieDyeh+eAcjr1tK7kGhsg8QzxDEiEL7Byvt1Dpe8 GeCXpYLqSQMvXidssdnUfIY3hySVlFIkCTbGBMhPGwTe6W8W7x+OJg/ujqXL41+XVzJh Dy3YztPTNTOw4z/xc4FOtM71MCuv0PCE00kWh7QTFPakDhm686LZAXwngo8IT7IgNki8 LIWHFEv/wCmV5uDD/tyK+ZqmbcduJKLnTuP9DAPk+IIOSm1K3Ij/G/+ze2ePRFOc0KiB KD6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ch1qkNHLGu6Fx1PsuGU0QmheKQltF8emaYDvwlqcgKo=; b=Pl7E0k4tYLolIH+tY+r7ERolD6mKZSleey2LqYuYGzTnuzIM9KQJfjkpqfLfXRQM2m 9irNAbVvMYZTP2nXxbK1zMo2Mgv141HfNlFQ/q5fqcPNYZ8x91kBWDXSfQW5BvnyfhbF tVwNng7yypWfWqLae3r1/WOtLcnuLVpsPyCa2l+QoVr0l7uwNyQ6wYkzuCudnBJXQPcN KGV0EJETzUlR9es0sPIQLMF4QzXauhsKDNasSTqcwzxD2mklP85RGCwfRJvkBz0oE0qc a8jgLQygMpI3GV265nX1AABziMGyZ/fcUhQuUz1Rza5JttMjaY0icioOT0C7Q+qkx4f0 b0ZQ== X-Gm-Message-State: AODbwcC9yVCEhg97fvJDS+rJPB4NzVx8S5qrYVlhYUKC2ztOtx2fmEZn KUwRVU6f6f/JDtC0a6q0TzIpRYkPWg== X-Received: by 10.101.72.135 with SMTP id n7mr35460819pgs.198.1496895498223; Wed, 07 Jun 2017 21:18:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.207.228 with HTTP; Wed, 7 Jun 2017 21:18:17 -0700 (PDT) In-Reply-To: <201706072043.38076.davemgarrett@gmail.com> References: <201706070223.19120.davemgarrett@gmail.com> <201706072043.38076.davemgarrett@gmail.com> From: Watson Ladd Date: Wed, 7 Jun 2017 21:18:17 -0700 Message-ID: To: Dave Garrett Cc: Piotr Sikora , Alessandro Ghedini , "tls@ietf.org" , "draft-ghedini-tls-certificate-compression@ietf.org" Content-Type: multipart/alternative; boundary="089e0823787470060105516b245c" Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2017 04:18:21 -0000 --089e0823787470060105516b245c Content-Type: text/plain; charset="UTF-8" On Wed, Jun 7, 2017 at 5:43 PM, Dave Garrett wrote: > On Wednesday, June 07, 2017 07:03:55 am Piotr Sikora wrote: > > > Additionally, there's one bit of the spec which I question the need > for: zlib support. Unless someone can show a legitimate case where zlib > will consistently and notably outperform brotli, I don't see the point in > defining it as an option. This is a bran new extension; we don't need > backwards compatibility here. There's been a general consensus in this WG > to avoid algorithm agility unless there's a real reason for it, so I > propose we ditch zlib support and make brotli the default and only > specified at the start (promoting it to id 0). Should some problem arise in > the future where we actually need to use a decades old compression > algorithm, it can be added later. Furthermore, we should probably define a > pre-defined dictionary for brotli to use here which is based on common > strings in certificates, rather than its default one for the general web > (if such a thing is practical to do here). This could boost efficiency here > and make it even more worth preferring (also likely reducing t > he size of said dictionary, as the default one is 120kB). > > > > To play devil's advocate, why do suggest we ditch zlib and not Brotli? > > > > I just did an experiment using certificate chains for facebook.com > > (ECDSA) and google.com (RSA). > > > [...snip...] > > > > As you can see, at level 1, Brotli is easily outperformed by gzip with > > and without dictionary, at level 6, both are basically the same, and > > at level 9/Z, Brotli wins by a small margin in terms of file size. > > > > However, you need to keep in mind that Brotli has significantly higher > > cost of compression, both in terms of CPU and memory allocations > > (>40MB at higher levels), which might be unacceptable in some > > environments. > > > > Don't get me wrong, I'm a big fan of Brotli, but unless we want to > > squeeze every single byte out of the compression and/or use > > pre-compressed certificates, then maybe Brotli isn't the best and only > > choice here? > > This is a convincing argument to me. Thanks for the data. Given this > information, I agree that supporting both algorithms can be helpful here, > depending on server hardware constraints. > > I'm still curious to know if we can potentially create a lightweight > cert-specific dictionary here that can boost things a bit. Or, is the QUIC > one largely based on certs too? > > As to your devil's advocate suggestion: ... yeah, if Brotli doesn't give > us any useful gains here over zlib, even with a new dict, I'd be ok with > not specifying it for use. Your test does show it getting a small win at > max compression, so that may not be the case. After fiddling with defining > a new dict, test data against a larger set of certs could be useful. > I'm not sure what units we are measuring in here: 222% of what? And what exactly is wrong with special formats that be much more compact on embedded devices, or enabling point compression? If you want root+intermediate+leaf that's 224 bytes of keys and signatures. Being sparing in extra data can probably have <300 byte chains, without the CPU overhead of compression at the cost of compatibility. > > Dave > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. --089e0823787470060105516b245c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 7, 2017 at 5:43 PM, Dave Garrett <davemgarrett@gmail.= com> wrote:
On Wednesday, June 07, 2017 07:03:55 am Piotr Sikora wrote:
> > Additionally, there's one bit of the spec which I question th= e need for: zlib support. Unless someone can show a legitimate case where z= lib will consistently and notably outperform brotli, I don't see the po= int in defining it as an option. This is a bran new extension; we don't= need backwards compatibility here. There's been a general consensus in= this WG to avoid algorithm agility unless there's a real reason for it= , so I propose we ditch zlib support and make brotli the default and only s= pecified at the start (promoting it to id 0). Should some problem arise in = the future where we actually need to use a decades old compression algorith= m, it can be added later. Furthermore, we should probably define a pre-defi= ned dictionary for brotli to use here which is based on common strings in c= ertificates, rather than its default one for the general web (if such a thi= ng is practical to do here). This could boost efficiency here and make it e= ven more worth preferring (also likely reducing t
=C2=A0he size of said dictionary, as the default one is 120kB).
>
> To play devil's advocate, why do suggest we ditch zlib and not Bro= tli?
>
> I just did an experiment using certificate chains for facebook.com
> (ECDSA) and google.com (RSA).
>
[...snip...]
>
> As you can see, at level 1, Brotli is easily outperformed by gzip with=
> and without dictionary, at level 6, both are basically the same, and > at level 9/Z, Brotli wins by a small margin in terms of file size.
>
> However, you need to keep in mind that Brotli has significantly higher=
> cost of compression, both in terms of CPU and memory allocations
> (>40MB at higher levels), which might be unacceptable in some
> environments.
>
> Don't get me wrong, I'm a big fan of Brotli, but unless we wan= t to
> squeeze every single byte out of the compression and/or use
> pre-compressed certificates, then maybe Brotli isn't the best and = only
> choice here?

This is a convincing argument to me. Thanks for the data. Given this= information, I agree that supporting both algorithms can be helpful here, = depending on server hardware constraints.

I'm still curious to know if we can potentially create a lightweight ce= rt-specific dictionary here that can boost things a bit. Or, is the QUIC on= e largely based on certs too?

As to your devil's advocate suggestion: ... yeah, if Brotli doesn't= give us any useful gains here over zlib, even with a new dict, I'd be = ok with not specifying it for use. Your test does show it getting a small w= in at max compression, so that may not be the case. After fiddling with def= ining a new dict, test data against a larger set of certs could be useful.<= br>

I'm not sure what units we are meas= uring in here: 222% of what? And what exactly is wrong with special formats= that be much more compact on embedded devices, or enabling point compressi= on?

If you want root+intermediate+leaf that's = 224 bytes of keys and signatures. Being sparing in extra data can probably = have <300 byte chains, without the CPU overhead of compression at the co= st of compatibility.



Dave

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



--
=
"Man= is born free, but everywhere he is in chains".
--Rousseau.
--089e0823787470060105516b245c-- From nobody Thu Jun 8 02:39:29 2017 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 3298E12E04D; Thu, 8 Jun 2017 02:39:28 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.53.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149691476818.25640.16315986205244926047@ietfa.amsl.com> Date: Thu, 08 Jun 2017 02:39:28 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-certificate-compression-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 08 Jun 2017 09:39:28 -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 : Transport Layer Security (TLS) Certificate Compression Authors : Alessandro Ghedini Victor Vasiliev Filename : draft-ietf-tls-certificate-compression-00.txt Pages : 6 Date : 2017-06-08 Abstract: In Transport Layer Security (TLS) handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-certificate-compression/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-certificate-compression-00 https://datatracker.ietf.org/doc/html/draft-ietf-tls-certificate-compression-00 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 Thu Jun 8 16:45:57 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0B8129B59 for ; Thu, 8 Jun 2017 16:45:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.002 X-Spam-Level: X-Spam-Status: No, score=-2.002 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, RP_MATCHES_RCVD=-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=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 kxGZhSdoSaYO for ; Thu, 8 Jun 2017 16:45:52 -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 C8CDB129B57 for ; Thu, 8 Jun 2017 16:45:52 -0700 (PDT) Received: by mail-ua0-x232.google.com with SMTP id q15so26685903uaa.2 for ; Thu, 08 Jun 2017 16:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=v5HKU0aMKv0R3sphS2ioVEBoWq9qjaqDBcxKorScbwE=; b=f2mWi4t2EA5CZyqCfM2lHlKJQDXOrCsB35Hk4/KZSRsTQnOjD8K1yuu2gBbUMQdK7+ L0d8Cb7Ua6A60foeiQltKX7Iw/AJLSHKkaNAcWqsfSs/47VNlkQMtEsrlzehkXq/WeLc g3qISMo1RLwPIqZMCFdoQQ2D7OkGvMx0xQvjazX1Ss/o6fET88A5nz1vITATEG66nOSb rqeaacdY435eUhrj8g2bAPgkcGrZQvKUd7dIL2VyoJ4f4wVFr7og8WFEvRtr62k2scEt tXBRqx0rH18EwxBq5HLf0167HcnP3t7KOlOintjvmImu434oTYbCWCjcChcv5eTQpyDd NffQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=v5HKU0aMKv0R3sphS2ioVEBoWq9qjaqDBcxKorScbwE=; b=pOLRSCZ2y9QEHgwfwMpY2oZD5osxUQ2ViBjHn9BzxhVcUckNnAyPPbNz9MIPKahLtP JW7eCwjsgUuCAR2y33jVjGXxLmYLHjigXG/jjJHNruHXl4Ii5pEA4bBHt8eLuGJ6JQqP qzFv93946ID/eCcmJ/EGgsecxch2TAJRLaqBcAI/T58W7Lj8SATbCEJnVOTqcno+wuUh xdW6lcROCc4R89gcTcJh2LDmEJ7nxn2XIajQbwQHLaWH9g0bWo51ju6GakrMhr6vlQUG ZUeOUFeN2goa9QgHpR7eALItBHlYh4hCaRZLo17Z25BvZ2iC8sF/E7MB2oy+X2sJC4G3 sW3Q== X-Gm-Message-State: AODbwcCqw/Sv2OjXI2pLT3rZmlL1kXnJHnS6fxY2WoTb8/65Un8F2a+D IAKSDw1HAu9Xu30Gc+GZ2GxYyvpRtBfv X-Received: by 10.176.4.67 with SMTP id 61mr19592709uav.47.1496965551751; Thu, 08 Jun 2017 16:45:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.153.131 with HTTP; Thu, 8 Jun 2017 16:45:51 -0700 (PDT) In-Reply-To: <201706072043.38076.davemgarrett@gmail.com> References: <201706070223.19120.davemgarrett@gmail.com> <201706072043.38076.davemgarrett@gmail.com> From: Piotr Sikora Date: Thu, 8 Jun 2017 16:45:51 -0700 Message-ID: To: Dave Garrett Cc: tls@ietf.org, "draft-ghedini-tls-certificate-compression@ietf.org" , Alessandro Ghedini , Victor Vasiliev Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 08 Jun 2017 23:45:55 -0000 Hi, > I'm still curious to know if we can potentially create a lightweight cert= -specific dictionary here that can boost things a bit. Or, is the QUIC one = largely based on certs too? It's based on certificates, from Chromium's QUIC code: // kCommonCertSubstrings contains ~1500 bytes of common certificate substri= ngs // in order to help zlib. This was generated via a fairly dumb algorithm fr= om // the Alexa Top 5000 set - we could probably do better. You can see the dictionary here: https://chromium.googlesource.com/chromium/src/+/19c30774eedcef459c776bde1c= 06e75bd48bf71e/net/quic/core/crypto/cert_compressor.cc#19 I've opened https://github.com/tlswg/certificate-compression/issues/1 to track this. > As to your devil's advocate suggestion: ... yeah, if Brotli doesn't give = us any useful gains here over zlib, even with a new dict, I'd be ok with no= t specifying it for use. Your test does show it getting a small win at max = compression, so that may not be the case. After fiddling with defining a ne= w dict, test data against a larger set of certs could be useful. FWIW, Brotli encryption at top compression levels (10 & 11) is quite expensive, so it probably only makes sense for pre-compressed certificates and possibly for one-time compression when loading certificates. Best regards, Piotr Sikora From nobody Fri Jun 9 00:03:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BB94126C25; Fri, 9 Jun 2017 00:03:15 -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 wZUMvHCk5Zol; Fri, 9 Jun 2017 00:03:13 -0700 (PDT) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 5817612946D; Fri, 9 Jun 2017 00:03:04 -0700 (PDT) Received: by mail-lf0-x231.google.com with SMTP id p189so26182323lfe.2; Fri, 09 Jun 2017 00:03:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TssgRkFrIdsSx19Q80o2c+4zF1ns/Nq7Nl0MB+nI7+o=; b=YT8wrogdP6FPKq0yqhLmIo2dkXwwdXOsdcETehcKQmCvBn3Y21Q3VJqRoyoTX0+mp7 ujYmd/Vt7xEPMjMMJGEcL/stGWwRNtUXn5euy9d3cRYwRbH0tl3B0JnG8gbmrDoWfE80 jEcmjVMqOB0rMo0dsHDB2y79YnzD0//iFL/0vGRgm1sEAR7JXg2Fru9pM3Xu6dSQIKDG kEy7rGxS3+LzImoUaj3KuWugkjMnVRuXack4sv6bQAPzEd9mOXerUsfy6GJdIdnIAEBM lXMORgb+S9Utg5v993YYr0lM+sViVL2Kv2dwD1GeI0ln7zX8Xvjm/cb7L+X+W8y+YYam txLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TssgRkFrIdsSx19Q80o2c+4zF1ns/Nq7Nl0MB+nI7+o=; b=WYCRSUwVWRGv5L9K8x7HfnO/ppJykLHj/HQ7Csnn5eek9qMBTxdzQPfSXFsmm/6bME 5Wcd2v/GrLYfdipd3XpSBeprUZW2EgH96ovDizIlZfx99dS1qaL/sR9hz1oGjZycvn88 jXSV74OebcK+fPsR+NTYQR8cgLwgbmbs7UyEQTAjJyLmVI4cZAqOLyvmctDp0MCy0ryy wXLv1szEoE84fPLOx9g0+/O8ViTuBD0rcnVAAztHfQ8NDo+AWOahph3QdF7SeuFh2Ae+ 8qcykX9EseOKEI8QY1etljfto89KINiI5lGb2CBSQUpYAbgnxSx1CZXL0CEWGExZ976O igLw== X-Gm-Message-State: AODbwcASPQbERXnShFhvrd+R8v4MoP0ee01/HpcEJ31GwOiIqW4disac e9oLNf3T7uwGH8fkdRjobKUIzQMGIQ== X-Received: by 10.25.217.77 with SMTP id q74mr6375115lfg.50.1496991782667; Fri, 09 Jun 2017 00:03:02 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.8.66 with HTTP; Fri, 9 Jun 2017 00:03:01 -0700 (PDT) In-Reply-To: References: <201706070223.19120.davemgarrett@gmail.com> <201706072043.38076.davemgarrett@gmail.com> From: Martin Thomson Date: Fri, 9 Jun 2017 09:03:01 +0200 Message-ID: To: Piotr Sikora Cc: Dave Garrett , Alessandro Ghedini , "tls@ietf.org" , "draft-ghedini-tls-certificate-compression@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] adopted: draft-ghedini-tls-certificate-compression X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jun 2017 07:03:15 -0000 On 9 June 2017 at 01:45, Piotr Sikora wrote: > FWIW, Brotli encryption at top compression levels (10 & 11) is quite > expensive, so it probably only makes sense for pre-compressed > certificates and possibly for one-time compression when loading > certificates. Certificates don't change that often... From nobody Fri Jun 9 06:55:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB80127B57 for ; Fri, 9 Jun 2017 06:55:10 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 rznXsH6XnAvj for ; Fri, 9 Jun 2017 06:55:08 -0700 (PDT) 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 E271C127843 for ; Fri, 9 Jun 2017 06:55:08 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id A314AB80D5B; Fri, 9 Jun 2017 06:55:02 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.com, Kathleen.Moriarty.ietf@gmail.com, ekr@rtfm.com, joe@salowey.net, sean+ietf@sn3rd.com X-PHP-Originating-Script: 30:errata_mail_lib.php From: RFC Errata System Cc: stefan.goeman@devoteam.com, tls@ietf.org, rfc-editor@rfc-editor.org Content-Type: text/plain; charset=UTF-8 Message-Id: <20170609135502.A314AB80D5B@rfc-editor.org> Date: Fri, 9 Jun 2017 06:55:02 -0700 (PDT) Archived-At: Subject: [TLS] [Technical Errata Reported] RFC5246 (5036) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jun 2017 13:55:10 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata/eid5036 -------------------------------------- Type: Technical Reported by: Stefan Goeman Section: 7.4.1.2 Original Text ------------- The ClientHello Structure indicates that a SessionID could be present. However if I take a wireshark of a TLS session I always see a "Session ID Length" field, either with value 0 or value 32 Corrected Text -------------- In the ClientHello structure and ServerHello structure, include a 1 byte "Session ID Length" field. Notes ----- The ClientHello Structure indicates that a SessionID could be present. However if I take a wireshark of a TLS session I always see a "Session ID Length" field, either with value 0 or value 32. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Fri Jun 9 07:03:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05294129435 for ; Fri, 9 Jun 2017 07:03:44 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 AV2ObF9hZts2 for ; Fri, 9 Jun 2017 07:03:41 -0700 (PDT) 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 B7E7A1241FC for ; Fri, 9 Jun 2017 07:03:41 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id e142so13257171ywa.1 for ; Fri, 09 Jun 2017 07:03:41 -0700 (PDT) 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=/AH42CDZfe0Y6yuSYMWr8ibBUv7B+6xuRHdX7nXxINE=; b=I6ZX7YcbwgsHQGQv48ymWh92j8uQOgZzgl+rgZyF1jkY89U6PkjOFF6l1QZkHQDBm8 eFKuDa3KrfnkKeb3Lx/u1b5Q28SD5RVwqd23uebu1ZeEn1rauBoJEGlhf0rTWlYsvlJf 7+UU9Cw74lrNYzhXaAqZjcCzn06RXGjZKfZx+jNcm10niqQBFkqFBpHhhWTMPhHCC9kr 9I45TajX26Ym/+qR0L9MQjuZ7Kr5l6eHVjflfzOYAwBnN/e1RHC33nB7xyEK5g0fPEFW 8Rz5fbz6ZV+TMKOMDqqIW+F8H3Q7Bpx4IQREtyPsJ4JII8EEM98ux+aiUl+121pOdMn/ Kg8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/AH42CDZfe0Y6yuSYMWr8ibBUv7B+6xuRHdX7nXxINE=; b=WXYzPogWysjT1nXVP9yhx+sehZHyHDZCakWHXjGW8MOnM8RmQdrD+libz0JnUUopEI Y4sIYLLqPSRM9u5BGZ9ja+SZL/f+DdeVfmafpvOPNzyWsrA2mB8RMyOXf/yp0euwkBxC ah0kL/BrRu3rGh7Oblteu++L1n4/lD/3lDT5fC29y++7DJaVO/B9wKERG+snXQbrhApG fpUkjQFGd0NeOBurIsEvbp2yjeOGDA8xcjO4VVA9+jYHeu40ElkXK3LZtFHavL0s3ucU lvTOFh1bHtnCm495VlrcC1BG91Fq3Wog5ONpXl8cazoQWV0tIL8rC7E++6rw7/+xDe7O qjoA== X-Gm-Message-State: AODbwcA10SJjyIDt9B/7ElsHbd+pVE8VSIvmgtBGSj28NIomzlh7tv86 q2nlu7ezg6Ef3HPh2JMKXQgZ9qoCFhyO X-Received: by 10.129.68.10 with SMTP id r10mr12019232ywa.85.1497017020473; Fri, 09 Jun 2017 07:03:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Fri, 9 Jun 2017 07:02:59 -0700 (PDT) In-Reply-To: <20170609135502.A314AB80D5B@rfc-editor.org> References: <20170609135502.A314AB80D5B@rfc-editor.org> From: Eric Rescorla Date: Fri, 9 Jun 2017 15:02:59 +0100 Message-ID: To: RFC Errata System Cc: Tim Dierks , Kathleen Moriarty , Joseph Salowey , sean+ietf@sn3rd.com, stefan.goeman@devoteam.com, "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045eb768ba7b850551876f20" Archived-At: Subject: Re: [TLS] [Technical Errata Reported] RFC5246 (5036) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 09 Jun 2017 14:03:44 -0000 --f403045eb768ba7b850551876f20 Content-Type: text/plain; charset="UTF-8" This erratum is incorrect. Here is the definition of SessionID: opaque SessionID<0..32>; The angle brackets mean that it is variable length and the 0..32 means that there is a one-byte length field. On Fri, Jun 9, 2017 at 2:55 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC5246, > "The Transport Layer Security (TLS) Protocol Version 1.2". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata/eid5036 > > -------------------------------------- > Type: Technical > Reported by: Stefan Goeman > > Section: 7.4.1.2 > > Original Text > ------------- > The ClientHello Structure indicates that a SessionID could be present. > However if I take a wireshark of a TLS session I always see a "Session > ID Length" field, either with value 0 or value 32 > > Corrected Text > -------------- > In the ClientHello structure and ServerHello structure, include > a 1 byte "Session ID Length" field. > > Notes > ----- > The ClientHello Structure indicates that a SessionID could be present. > However if I take a wireshark of a TLS session I always see a > "Session ID Length" field, either with value 0 or value 32. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > -------------------------------------- > Title : The Transport Layer Security (TLS) Protocol Version > 1.2 > Publication Date : August 2008 > Author(s) : T. Dierks, E. Rescorla > Category : PROPOSED STANDARD > Source : Transport Layer Security > Area : Security > Stream : IETF > Verifying Party : IESG > --f403045eb768ba7b850551876f20 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This erratum is incorrect.

Here is the = definition of SessionID:
=C2=A0 =C2=A0 =C2=A0 opaque SessionID<= ;0..32>;

The angle brackets mean that it is= variable length and the 0..32 means that there is
a one-byte len= gth field.

On Fri, Jun 9, 2017 at 2:55 PM, RFC Errata System &l= t;rfc-editor= @rfc-editor.org> wrote:
The= following errata report has been submitted for RFC5246,
"The Transport Layer Security (TLS) Protocol Version 1.2".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5036

--------------------------------------
Type: Technical
Reported by: Stefan Goeman <stefan.goeman@devoteam.com>

Section: 7.4.1.2

Original Text
-------------
The ClientHello Structure indicates that a SessionID could be present.
However if I take a wireshark of a TLS session I always see a "Session=
ID Length" field, either with value 0 or value 32

Corrected Text
--------------
In the ClientHello structure and ServerHello structure, include
a 1 byte "Session ID Length" field.

Notes
-----
The ClientHello Structure indicates that a SessionID could be present.
However if I take a wireshark of a TLS session I always see a
"Session ID Length" field, either with value 0 or value 32.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC5246 (draft-ietf-tls-rfc4346-bis-10)
--------------------------------------
Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: The Transport= Layer Security (TLS) Protocol Version 1.2
Publication Date=C2=A0 =C2=A0 : August 2008
Author(s)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: T. Dierks, E. Rescorla<= br> Category=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : PROPOSED STANDARD
Source=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Transport Layer Se= curity
Area=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : Security
Stream=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : IETF
Verifying Party=C2=A0 =C2=A0 =C2=A0: IESG

--f403045eb768ba7b850551876f20-- From nobody Sun Jun 11 08:18:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E9912441E for ; Sun, 11 Jun 2017 08:18:48 -0700 (PDT) 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 tgP3Fuz2cifK for ; Sun, 11 Jun 2017 08:18:46 -0700 (PDT) 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 98F37127011 for ; Sun, 11 Jun 2017 08:18:44 -0700 (PDT) Received: by mail-yw0-x22f.google.com with SMTP id 63so30457472ywr.0 for ; Sun, 11 Jun 2017 08:18:44 -0700 (PDT) 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=6SWnNl436DSyxubacVFKb+zPzE9NFdRwUSRCjo4nEpQ=; b=rspS9rwWtgZYZNhhLalvpvGekp3VP6Al/OVQvZy0JIO68qtcX/NIoBRuCKtC8qQ7sH H6mxuKRBX0OAox+/CH8X9eY63E5n1Mpv5PDct7UupVqaVYKid54bsKrzMYgIjXKOQSm5 rWEC7E1WAXCavBFvHCrPDvPgd7IuLZURrCbwMYbbgSaibilbVQdNYqMqDe6cV2Rkrmli 9qjGmMmrdJE9FbBX+dv/YBRT31IXPRrZPom01I17Y5Ch3j5mLJyW849jecdA+QStJh7l ZoZh55rreAt64EWW34h2zTcnJt6F3j4CAwSR6biV9JXFixFG4g7z+wukm+EZfiHRGYRU V9/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6SWnNl436DSyxubacVFKb+zPzE9NFdRwUSRCjo4nEpQ=; b=AsIbbRb66I5sCkz2gdXCv2tjmqRI6AB6xBDAb1hw1AoGL2X8zFNX0GZ+ubFck7liaB chu8mJf+WYv7p6WHmtr4fPu73OZA2U+wkVgMUQ1pQgVUCXPcDNr4ntGwpsRAzN8Gv/aK 79yvo7LY7vcRHIg3aAq8ZBn9EEN8FMxbiRHH3Akx4nj3IQ3pkOOEt9BU+Rlj6nin4v5w nd1COaToa6WTsAdN6sPQpfsZK1qv30jIHn5i8nS0RyYIWyacLO242mf0cxuscQPd3nFD 6z0Lt2AuWx7/8FFrYrCx4TTemTe9Gw3rSYK6vCB9AYA1Ur4pVsXmc9Aecrn1FjpInR6k 3Bjw== X-Gm-Message-State: AODbwcDd+EsX7ZZGnSljN3hwg1BJi3MpIWeTWAOGLzRevraT00uNom63 n9zFtHZGmRodTE41gsCYV+e70DjIFJgFyPdX/g== X-Received: by 10.129.146.9 with SMTP id j9mr21168680ywg.283.1497194323557; Sun, 11 Jun 2017 08:18:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Sun, 11 Jun 2017 08:18:03 -0700 (PDT) From: Eric Rescorla Date: Sun, 11 Jun 2017 16:18:03 +0100 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0928d4d0e4f50551b0b740" Archived-At: Subject: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jun 2017 15:18:48 -0000 --94eb2c0928d4d0e4f50551b0b740 Content-Type: text/plain; charset="UTF-8" Hi folks, We've had a phenomenal amount of discussion around 0-RTT anti-replay, and based on my recent summary e-mails I think we generally agree about the technical facts, so it's time to finalize the PR and land it in the specification. Here's what I propose to do: - Describe the attacks that Colm described. - Distinguish between replay and retransmission - Mandate (SHOULD-level) that servers do some sort of bounded (at-most-N times) anti-replay mechanism and emphasize that implementations that forbid replays entirely (only allowing retransmission) are superior. - Describe the stateless mechanism as a recommended behavior but not as a substitute for the other mechanisms. As Martin Thomson has pointed out, it's a nice pre-filter for either of these other mechanisms. - Clarify the behavior you need to get PFS. - Require (MUST) that clients only send and servers only accept "safe" requests in 0-RTT, but allow implementations to determine what is safe. Note: there's been a lot of debate about exactly where this stuff should go in the document and how it should be phrased. I think these are editorial questions and so largely my discretion. Here's what I do not intend to do. - Mandate (MUST-level) any anti-replay mechanism. I do not believe there is any WG consensus for this. - Design a mechanism to allow the server to tell the client that it either (a) enforces strong anti-replay or (b) deletes PSKs after first use. Either of these seem like OK ideas, but they can be added to NST as extensions at some future time, and I haven't seen a lot of evidence that existing clients would consume these. I recognize that nobody will be entirely happy with this, but I believe it most closely represents consensus. Assuming the chairs agree, I'd like to suggest a brief period of discussion on this proposal, followed by a consensus call, and then I'll generate a PR that enacts it. People will still have time to review that, but in order to avoid an endless round of dicussion, the idea will be able to review it for conformance to these principles, not to re-litigate these. -Ekr --94eb2c0928d4d0e4f50551b0b740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,

We've had a ph= enomenal amount of discussion around 0-RTT anti-replay,
and based= on my recent summary e-mails I think we generally agree
about th= e technical facts, so it's time to finalize the PR and land it
in the specification.


Here's = what I propose to do:

- Describe the attacks that = Colm described.

- Distinguish between replay and r= etransmission

- Mandate (SHOULD-level) that server= s do some sort of bounded
=C2=A0 (at-most-N times) anti-replay me= chanism and emphasize that
=C2=A0 implementations that forbid rep= lays entirely (only allowing
=C2=A0 retransmission) are superior.=

- Describe the stateless mechanism as a recommend= ed behavior but not
=C2=A0 as a substitute for the other mechanis= ms. As Martin Thomson has
=C2=A0 pointed out, it's a nice pre= -filter for either of these other
=C2=A0 mechanisms.
- Clarify the behavior you need to get PFS.

- Require (MUST) that clients only send and servers only accept &quo= t;safe"
=C2=A0 requests in 0-RTT, but allow implementations = to determine what is
=C2=A0 safe.

Note: = there's been a lot of debate about exactly where this stuff
s= hould go in the document and how it should be phrased.=C2=A0 I think these<= /div>
are editorial questions and so largely my discretion.
<= br>

Here's what I do not intend to do.

- Mandate (MUST-level) any anti-replay mechanism. I do no= t believe
=C2=A0 there is any WG consensus for this.
- Design a mechanism to allow the server to tell the client th= at it
=C2=A0 either (a) enforces strong anti-replay or (b) delete= s PSKs after
=C2=A0 first use. Either of these seem like OK ideas= , but they can be added
=C2=A0 to NST as extensions at some futur= e time, and I haven't seen a lot
=C2=A0 of evidence that exis= ting clients would consume these.

I recognize that= nobody will be entirely happy with this, but I
believe it most c= losely represents consensus. Assuming the chairs
agree, I'd l= ike to suggest a brief period of discussion on this
proposal, fol= lowed by a consensus call, and then I'll generate a PR
that e= nacts it. People will still have time to review that, but in
orde= r to avoid an endless round of dicussion, the idea will be able to
review it for conformance to these principles, not to re-litigate
these.

-Ekr


=
=C2=A0=C2=A0
=C2=A0=C2=A0







=C2=A0 =C2=A0 =C2=A0=C2=A0

--94eb2c0928d4d0e4f50551b0b740-- From nobody Sun Jun 11 09:26:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C5C5127843 for ; Sun, 11 Jun 2017 09:26: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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 KINZg0oMCQK5 for ; Sun, 11 Jun 2017 09:26:29 -0700 (PDT) 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 8A00D124BE8 for ; Sun, 11 Jun 2017 09:26:29 -0700 (PDT) Received: by mail-it0-x232.google.com with SMTP id m47so13255252iti.0 for ; Sun, 11 Jun 2017 09:26:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=kCRRzGdSRPfVywk4oQlQPAWWH8esnhYRg0NDHMEvFr0=; b=R0a0XvwDs4lPk+Ept8q+OJE5HKL+ARoCUdrXPPrQRiYJXb+RrWGU4khzJm1obgENpr i8La8Pv+xdudm9H2EkH/o5glNm4OG9r23TyC4+vwxRc4T1/JljkR+t5Lad6vjSlw+vPp 6h4lhm13MSz2G867lsh6WGs5OMyaglfvLYseY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=kCRRzGdSRPfVywk4oQlQPAWWH8esnhYRg0NDHMEvFr0=; b=BQm6QFwcWs5u5sas/L64MybUNjrNyy2tzBcuiUc6qXNvQi1k9gDlGu7kKz9etTM435 pBKiytJp7eGt/pg1LdGLbb5JIjdOHu2rvQIkt3A1KIDtWAhLH1F8cQDZWNECc1B1XMbM UcYu1QRwas8qy7XqID5bLUlMDAd1Wma7muGFtfqUjHE4dtjX4KKralPamXe8ZcutDjnk S+1VYud7eDGnh5mJXuL+mFuSS4nVkD8M5lR7uU5cPX+4C4TQ4O2hMqfZKqjdZd+VxBGt 7pc985TS2aGd95IeAImzgfaYqxJKomr0vskGSeq5YntvChlsV//OIL9zvo7BnjvTlVi9 fDog== X-Gm-Message-State: AODbwcAARp9z22VoA3QzMX4qlxFcn4LzIAaYfMsKXuEEVM4uF1QuJscT vbneIdlnlev7H4fkZUHqhg== X-Received: by 10.36.53.70 with SMTP id k67mr8560101ita.79.1497198388395; Sun, 11 Jun 2017 09:26:28 -0700 (PDT) Received: from [5.5.33.68] (vpn.snozzages.com. [204.42.252.17]) by smtp.gmail.com with ESMTPSA id 204sm2854388itu.19.2017.06.11.09.26.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Jun 2017 09:26:27 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Sun, 11 Jun 2017 12:26:14 -0400 References: <8B97253B-2A79-421E-BD5D-732128525520@sn3rd.com> To: "" In-Reply-To: <8B97253B-2A79-421E-BD5D-732128525520@sn3rd.com> Message-Id: X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] merging PR#998 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jun 2017 16:26:31 -0000 ekr it=E2=80=99s okay to merge this PR. spt > On Jun 4, 2017, at 01:43, Sean Turner wrote: >=20 > All, >=20 > It looks like PR#998 (https://github.com/tlswg/tls13-spec/pull/998), = which was discussed in this in this monster thread = (https://mailarchive.ietf.org/arch/msg/tls/mHxi-O3du9OQHkc6CBWBpc_KBpA), = is ready to be merged; ekr actually asked if it was okay to merge back = on 16 May. Please let list know by COB 9 June (in whatever timezone = you=E2=80=99re in) if you object to merging it and why. >=20 > spt From nobody Sun Jun 11 11:40:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38C14127419 for ; Sun, 11 Jun 2017 11:40: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 Dr8Vcc5ww9GF for ; Sun, 11 Jun 2017 11:40:05 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 78ABF128616 for ; Sun, 11 Jun 2017 11:40:05 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id u19so106570091qta.3 for ; Sun, 11 Jun 2017 11:40:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-transfer-encoding:message-id; bh=h4DBcN4fI97b1YKP0lzyVpeT/isa1swiLHRFVsN91LY=; b=d0nsN63BXFaMiOou0YTPkFCU4FebAHjz0DkG/cXq5zOeXT7G1JLuyO0nf3K4dUqLah 8jbmVqC/rs4FGnL5+wMbzt1NxWIS/koc9LUm+aibEqgakJt03kcJ/Y0bRtwhOTzDROs6 hsc0WzgRidu1jkU0fYTX0JALvbpfyIpVUqJKVxhPQAKNqvXqMMXQG85T59Js2IqGXvzT Wjvg3xzwGhxg6dBwRuSlGseNeWsAuyFoow0DWCM3Tu7O/u1/7eJjemp8orRKnAG8U6j0 zkMucQqmA0gOT5QjXQBTe9yT6u1koGksi+tcLTcPS7fK4nq61RsO2Ow4nIwwhClFri5E ADLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:user-agent:cc:references :in-reply-to:mime-version:content-transfer-encoding:message-id; bh=h4DBcN4fI97b1YKP0lzyVpeT/isa1swiLHRFVsN91LY=; b=BpJ7U5DJY4KZW6kJz9BpfSlckuplYSnuTdijEUqd55OIwllq/n9YBkkVOQItvgHxeJ M0nDGIcdN3t+g0jynMxOQWwPBamXyCYShtOv+Ba+i2hZ2kDZPEeC5vF1FbnMVvloHMZj GPYN8ei7BkLBvfyvua9SjYJp50ENxpmuTCDoU371zKrFm0BnF6xSYLE7Hb/YpgQ5hHMA KxeImlrMWJ76eAphIdAnfaiYj+k6HDfSPn0ejfDBqK5x6WnKa2CaBqk3cXp6eM45cJj1 blREPqPXDv1XC7yWeI84A+w9L18vr6J1z4nRV65igO08uT6xbi48BM/ruiGpTw2Enjcl fyDQ== X-Gm-Message-State: AODbwcDjYiUQn2tZHbq/nv6zofyr9QxLOFuFll25QFpkvDfJ0zMJXATr 0/Rzy9UOUsx8Zfb8 X-Received: by 10.200.37.1 with SMTP id 1mr14175935qtm.216.1497206404553; Sun, 11 Jun 2017 11:40:04 -0700 (PDT) Received: from dave-laptop.localnet (pool-71-175-70-41.phlapa.fios.verizon.net. [71.175.70.41]) by smtp.gmail.com with ESMTPSA id 8sm4947719qki.40.2017.06.11.11.40.03 (version=TLS1 cipher=AES128-SHA bits=128/128); Sun, 11 Jun 2017 11:40:03 -0700 (PDT) From: Dave Garrett To: tls@ietf.org Date: Sun, 11 Jun 2017 14:40:02 -0400 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-6" Content-Transfer-Encoding: quoted-printable Message-Id: <201706111440.02647.davemgarrett@gmail.com> Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 11 Jun 2017 18:40:07 -0000 On Sunday, June 11, 2017 11:18:03 am Eric Rescorla wrote: > Here's what I propose to do: [...] > - Mandate (SHOULD-level) that servers do some sort of bounded > (at-most-N times) anti-replay mechanism and emphasize that > implementations that forbid replays entirely (only allowing > retransmission) are superior. [...] > Here's what I do not intend to do. [...] > - Mandate (MUST-level) any anti-replay mechanism. I do not believe > there is any WG consensus for this. Whilst bounded replay protection isn't ideal, I wasn't aware of it being op= posed to the point where we couldn't make it the bare minimum. There really= needs to be some floor to the mess here. If I've followed all of the discussion accurately, there may be a rough con= sensus that mandating with a MUST-level _some_ kind of anti-replay mechanis= m which MAY be implemented at the application layer as appropriate. (with a= SHOULD-level requirement that it be done in the TLS implementation; MUST-l= evel if we can actually agree to mandate bounded as a minimum, with better = handling at the application level) In other words, either the TLS implement= ation MUST have replay protection or the application protocol profile MUST = have its own replay protection (instead, or preferably in addition to a bar= e minimum). Replay protection would be required by TLS, but could be delega= ted to the application; people that want to do really unsafe stuff can defi= ne its replay handling mechanics there. This (heavily qualified) set of req= uirements would define TLS to be safe, so long as people stay within the kn= own bounds laid out by the spec and profile(s) (with the potential for dubi= ous profiles hand waved away...). Dave From nobody Mon Jun 12 11:12:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8C9012EB4E for ; Mon, 12 Jun 2017 11:12:30 -0700 (PDT) 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=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 gIZnjqtmtqyb for ; Mon, 12 Jun 2017 11:12:28 -0700 (PDT) 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 7C65F12EACE for ; Mon, 12 Jun 2017 11:12:28 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id e142so31044085ywa.1 for ; Mon, 12 Jun 2017 11:12:28 -0700 (PDT) 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=Rzx+qlFE2xPUtIsaSEsELLR2AZq4un4fRKymsXCvSqc=; b=CoKIV7Dc4VGO5rFWFEBh+5Ig7hPNuK6ieBq95SInRtPQgLRBK3EvmyjSq/HQYKIb3y WZ/uUvSM7ixaK4U7eFfSTEwVusY/ddZRSTLQp9IH+bIjwDpV0CIMLmXPMsPonkz1towk ambhxkZK/SE7aO2nh4afXmqYCUD6VvZ6eJFc74q1N5x2EbW/2guM7adn73yxGkhUP+pB +52+h6FXOkj9PCpW8BJKkEiF1hAh0NdyTbosIWv+4AOlY3j47GLk5jra0svMtsorVo4j cfroJknz4anOHwnnC1Wg86HpXUmFMtZnjSP76h5evdK1ntsENoGi8p2AdAGhk17EFHZX EUzw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Rzx+qlFE2xPUtIsaSEsELLR2AZq4un4fRKymsXCvSqc=; b=CtIZr5HubDxdbz/E+UNgFqUiZltQ2PZJSU/KHnkQMzBi//ujya5YgE3UVBeRtQh2SI XKDyjB0HSMJdiENDr4nskafhOuooMJucQ4BkjGYV/qXel/OjpFISJWAAGFzawfZ5+hPZ bxtKRSQQLnqALLKsRolk8PeCClWMKsRHo/ZJ9cGDqTIBmOk+DzKaHCCGuPjT91bYVib4 GokruT6D3/+pwpNjLVdu8ty8pnGtdNcz1Oge88aF8C29lUZT+q/qol7KN+GmuddEVxa0 nWl/6l78/YY4PmqEKiMPU8kqdqh9zCdi58ii4DiapxNUcG+jrEE1aYsCe9IbdZnI7k7Y Y0ZQ== X-Gm-Message-State: AKS2vOyiz6tlKJ8S/d6NyoHrq4B+27sFfChQ70Ac82HoSzL8FczjtzvN PXytRppFZ4hzKwM32Mep6FfvDTwPaXUJ X-Received: by 10.129.172.39 with SMTP id k39mr203414ywh.74.1497291147591; Mon, 12 Jun 2017 11:12:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.93.70 with HTTP; Mon, 12 Jun 2017 11:12:27 -0700 (PDT) In-Reply-To: References: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 12 Jun 2017 11:12:27 -0700 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045e56acfa57b00551c742a5" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2017 18:12:31 -0000 --f403045e56acfa57b00551c742a5 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 11, 2017 at 8:18 AM, Eric Rescorla wrote: > Here's what I propose to do: > > - Describe the attacks that Colm described. > > - Distinguish between replay and retransmission > > - Mandate (SHOULD-level) that servers do some sort of bounded > (at-most-N times) anti-replay mechanism and emphasize that > implementations that forbid replays entirely (only allowing > retransmission) are superior. > > - Describe the stateless mechanism as a recommended behavior but not > as a substitute for the other mechanisms. As Martin Thomson has > pointed out, it's a nice pre-filter for either of these other > mechanisms. > > - Clarify the behavior you need to get PFS. > > - Require (MUST) that clients only send and servers only accept "safe" > requests in 0-RTT, but allow implementations to determine what is > safe. > > Note: there's been a lot of debate about exactly where this stuff > should go in the document and how it should be phrased. I think these > are editorial questions and so largely my discretion. > First of all, thanks for doing this, that all sounds great! The TLS spec is obviously monumentally important to the internet, and years of hard work aren't made easier by late-coming changes, that shouldn't be thankless. > Here's what I do not intend to do. > > - Mandate (MUST-level) any anti-replay mechanism. I do not believe > there is any WG consensus for this. > The one case here where I'd really argue for a "MUST" is middle-boxes like CDNs. The concern I have is if someone has an application that uses throttling or is vulnerable to a resource-exhaustion problem and goes and puts a CDN in front of it, it's not obvious that enabling TLS 1.3 could open them to a new kind of DOS attack. We've already seen CDNs enable TLS 1.3 with unintentionally broken 0-RTT mitigations, so that's clear evidence that the existing guidance isn't sufficient. I think it would help manage the interoperability risks if we can point out to their customers that the configuration is unambiguously broken. Or at least, it helps to flag it as a security issue, which makes it more likely to get fixed. Absent this, the operators of "backend" applications would have to live with risk that is created by the upstream CDN providers for their own convenience. That seems like a really bad interoperability set up. I'd argue for at-most-once protection here, since that's the only way a client can make deterministic decisions, and it's also easier to audit and GREASE. But there doesn't seem to be consensus around that. At the moment, I feel that's a bit like the lack of consensus the "Clean coal" industry has on global warming though, because it seems to be an argument rooted in operational convenience rather than actual security. This is not the standard we apply in other cases; we wouldn't listen to those who say that it's ok to keep RC4 or MD5 in the standard because the problems are small and the operational performance benefit is worth it. My spidey-sense is that these attacks will get better and more refined over time. Nevertheless, /some/ guaranteed replay protection would be better than none. particularly in this case. So if it's at-most-N, and N is small enough to at least avoid many throttling cases, that's something worth taking, even though it does leave open the easier cache-analysis attacks. - Design a mechanism to allow the server to tell the client that it > either (a) enforces strong anti-replay or (b) deletes PSKs after > first use. Either of these seem like OK ideas, but they can be added > to NST as extensions at some future time, and I haven't seen a lot > of evidence that existing clients would consume these. > This can happen totally outside of the protocol too; as-in an operator can advertise it as a feature. Likely most useful for the forward secrecy case. -- Colm --f403045e56acfa57b00551c742a5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jun 11, 2017 at 8:18 AM, Eric Rescorla <ekr@rtfm.com>= wrote:
Here's = what I propose to do:

- Describe the attacks t= hat Colm described.

- Distinguish between replay a= nd retransmission

- Mandate (SHOULD-level) that se= rvers do some sort of bounded
=C2=A0 (at-most-N times) anti-repla= y mechanism and emphasize that
=C2=A0 implementations that forbid= replays entirely (only allowing
=C2=A0 retransmission) are super= ior.

- Describe the stateless mechanism as a recom= mended behavior but not
=C2=A0 as a substitute for the other mech= anisms. As Martin Thomson has
=C2=A0 pointed out, it's a nice= pre-filter for either of these other
=C2=A0 mechanisms.

- Clarify the behavior you need to get PFS.

=
- Require (MUST) that clients only send and servers only accept = "safe"
=C2=A0 requests in 0-RTT, but allow implementati= ons to determine what is
=C2=A0 safe.

No= te: there's been a lot of debate about exactly where this stuff
should go in the document and how it should be phrased.=C2=A0 I think th= ese
are editorial questions and so largely my discretion.

First of all, thanks for doing this, t= hat all sounds great! The TLS spec is obviously monumentally important to t= he internet, and years of hard work aren't made easier by late-coming c= hanges, that shouldn't be thankless.=C2=A0
=C2=A0
Here's what I do not int= end to do.

- Mandate (MUST-level) any anti-replay = mechanism. I do not believe
=C2=A0 there is any WG consensus for = this.

The one case here where I= 'd really argue for a "MUST" is middle-boxes like CDNs. The c= oncern I have is if someone has an application that uses throttling or is v= ulnerable to a resource-exhaustion problem and goes and puts a CDN in front= of it, it's not obvious that enabling TLS 1.3 could open them to a new= kind of DOS attack.=C2=A0

We've already seen = CDNs enable TLS 1.3 with unintentionally broken 0-RTT mitigations, so that&= #39;s clear evidence that the existing guidance isn't sufficient. I thi= nk it would help manage the interoperability risks if we can point out to t= heir customers that the configuration is unambiguously broken. Or at least,= it helps to flag it as a security issue, which makes it more likely to get= fixed. Absent this, the operators of "backend" applications woul= d have to live with risk that is created by the upstream CDN providers for = their own convenience. That seems like a really bad interoperability set up= . =C2=A0

I'd argue for at-most-once protection= here, since that's the only way a client can make deterministic decisi= ons, and it's also easier to audit and GREASE. But there doesn't se= em to be consensus around that. At the moment, I feel that's a bit like= the lack of consensus the "Clean coal" industry has on global wa= rming though, because it seems to be an argument rooted in operational conv= enience rather than actual security. This is not the standard we apply in o= ther cases; we wouldn't listen to those who say that it's ok to kee= p RC4 or MD5 in the standard because the problems are small and the operati= onal performance benefit is worth it. My spidey-sense is that these attacks= will get better and more refined over time.=C2=A0

Nevertheless, /some/ guaranteed replay protection would be better than non= e. particularly in this case. So if it's at-most-N, and N is small enou= gh to at least avoid many throttling cases, that's something worth taki= ng, even though it does leave open the easier cache-analysis attacks.=C2=A0=

-= Design a mechanism to allow the server to tell the client that it
=C2=A0 either (a) enforces strong anti-replay or (b) deletes PSKs after
=C2=A0 first use. Either of these seem like OK ideas, but they can= be added
=C2=A0 to NST as extensions at some future time, and I = haven't seen a lot
=C2=A0 of evidence that existing clients w= ould consume these.

This can ha= ppen totally outside of the protocol too; as-in an operator can advertise i= t as a feature. Likely most useful for the forward secrecy case.=C2=A0
=C2=A0
--
Colm
--f403045e56acfa57b00551c742a5-- From nobody Mon Jun 12 11:19:35 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E5C212EB5E for ; Mon, 12 Jun 2017 11:19:33 -0700 (PDT) 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=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 kNRamovwz2YY for ; Mon, 12 Jun 2017 11:19:31 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 8B4AB12EB5D for ; Mon, 12 Jun 2017 11:19:31 -0700 (PDT) Received: from pps.filterd (m0050102.ppops.net [127.0.0.1]) by m0050102.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5CIGrb5032500; Mon, 12 Jun 2017 19:19:28 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=+W88/ihL1t1Lt3sSX15AxWzN+7D5A4lMPhpfjqU0k84=; b=dx30HRXnrLyNAeRA3v0fgTLPQ/0/4tO+TYq1lemMGVu74QM4L2P6GZDhxTNgsPJZ0QT1 +pWUzHm26+WH2AwOSX9cV8lENT1U9pAZj4eGJpH50rUtefyRn7V6p8Gdm6RkeTqZKhV0 DecWM9JfzeuoHiG0KZDonvAykKkpIeJJGzH9JbaCyN7fRfAGZylVgkf8kdyNB2q3Ld3L kx840mSpwh2kemIQdiH3l9gnkfsuppMA///qB5CDLyM2//YCqo4leGXM29zpccSEPCuy Yi7sqgjJyaj4oltXpEHYRxnz8lYeDQMcszhwvjOvswfykrnSZ5pUh9iB0PMQc9p0wMbE 6Q== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050102.ppops.net-00190b01. with ESMTP id 2b1vnrsaru-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 19:19:27 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5CIGcKT022695; Mon, 12 Jun 2017 14:19:27 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.31]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b0c3u77ws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Jun 2017 14:19:27 -0400 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.1263.5; Mon, 12 Jun 2017 14:19:26 -0400 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.1263.000; Mon, 12 Jun 2017 14:19:26 -0400 From: "Salz, Rich" To: =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= , Eric Rescorla CC: "tls@ietf.org" Thread-Topic: [TLS] Closing on 0-RTT Thread-Index: AQHS4sYMYZjiI3AtlUaLYB0HLNHkW6IhzGeA//+956A= Date: Mon, 12 Jun 2017 18:19:25 +0000 Message-ID: <2e8816cf734e4bb78d36302c6910a82d@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.36.218] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120318 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-12_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706120318 Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2017 18:19:33 -0000 PiBUaGUgb25lIGNhc2UgaGVyZSB3aGVyZSBJJ2QgcmVhbGx5IGFyZ3VlIGZvciBhICJNVVNUIiBp cyBtaWRkbGUtYm94ZXMgbGlrZSBDRE5zLiBUaGUgY29uY2VybiBJIGhhdmUgaXMgaWYgc29tZW9u ZSBoYXMgYW4gYXBwbGljYXRpb24gdGhhdCB1c2VzIHRocm90dGxpbmcgb3IgaXMgdnVsbmVyYWJs ZSB0byBhIHJlc291cmNlLWV4aGF1c3Rpb24gcHJvYmxlbSBhbmQgZ29lcyBhbmQgcHV0cyBhIENE TiBpbiBmcm9udCBvZiBpdCwgaXQncyBub3Qgb2J2aW91cyB0aGF0IGVuYWJsaW5nIFRMUyAxLjMg Y291bGQgb3BlbiB0aGVtIHRvIGEgbmV3IGtpbmQgb2YgRE9TIGF0dGFjay7CoA0KDQpBIENETiBp cyBub3QgYSBtaWRkbGUgYm94LiAgSXQgKmlzKiBvcmlnaW4gYXMgZmFyIGFzIHRoZSBlbmQtdXNl cnMgYXJlIGNvbmNlcm5lZCwgYmVjYXVzZSBvZiB0aGUgYnVzaW5lc3MgcmVsYXRpb25zaGlwIGJl dHdlZW4gdGhlIENETiBhbmQgdGhlIGNvbnRlbnQgcHJvdmlkZXIuICBPciwgaWYgeW91IGRvbid0 IGxpa2UgdGhhdCByZWFzb25pbmcsIHRoZW4gaXQncyBub3QgYSBtaWRkbGVib3ggYXMgdGhlIElF VEYgdXNlcyB0aGUgdGVybS4NCg0KSWYgdGhlIGludGVybWVkaWFyeSBpcyB2dWxuZXJhYmxlIHRv IHRoZSByZXNvdXJjZSBhdHRhY2tzLCB0aGF0J3MgdGhlIGludGVybWVkaWFyeSdzIGlzc3VlLg0K DQo+IFdlJ3ZlIGFscmVhZHkgc2VlbiBDRE5zIGVuYWJsZSBUTFMgMS4zIHdpdGggdW5pbnRlbnRp b25hbGx5IGJyb2tlbiAwLVJUVCBtaXRpZ2F0aW9ucywgc28gdGhhdCdzIGNsZWFyIGV2aWRlbmNl IHRoYXQgdGhlIGV4aXN0aW5nIGd1aWRhbmNlIGlzbid0IHN1ZmZpY2llbnQuIEkgdGhpbmsgaXQg d291bGQgaGVscCBtYW5hZ2UgdGhlIGludGVyb3BlcmFiaWxpdHkgcmlza3MgaWYgd2UgY2FuIHBv aW50IG91dCB0byB0aGVpciBjdXN0b21lcnMgdGhhdCB0aGUgY29uZmlndXJhdGlvbiBpcyB1bmFt YmlndW91c2x5IGJyb2tlbi4gT3IgYXQgbGVhc3QsIGl0IGhlbHBzIHRvIGZsYWcgaXQgYXMgYSBz ZWN1cml0eSBpc3N1ZSwgd2hpY2ggbWFrZXMgaXQgbW9yZSBsaWtlbHkgdG8gZ2V0IGZpeGVkLiBB YnNlbnQgdGhpcywgdGhlIG9wZXJhdG9ycyBvZiAiYmFja2VuZCIgYXBwbGljYXRpb25zIHdvdWxk IGhhdmUgdG8gbGl2ZSB3aXRoIHJpc2sgdGhhdCBpcyBjcmVhdGVkIGJ5IHRoZSB1cHN0cmVhbSBD RE4gcHJvdmlkZXJzIGZvciB0aGVpciBvd24gY29udmVuaWVuY2UuIFRoYXQgc2VlbXMgbGlrZSBh IHJlYWxseSBiYWQgaW50ZXJvcGVyYWJpbGl0eSBzZXQgdXAuIMKgDQoNCkkgYWdyZWUgd2l0aCB0 aGlzLiAgV2hpY2ggaXMgd2h5IEkgcHJlZmVyIHNlcGFyYXRlIHN0cmVhbXMgZm9yIGVhcmx5IGRh dGEsIGFuZCBzb21lIGtpbmQgb2Ygc2lnbmFsaW5nIHRvIHRoZSBjb250ZW50IHByb3ZpZGVyIHRo YXQgaXMgY2xlYXIgYW5kIHVuYW1iaWd1b3VzLiAgSSBkb24ndCBrbm93IGhvdyB0byBkbyB0aGF0 IHdoZW4sIHNheSwgdGhlIGludGVybWVkaWFyeS9DRE4gaGFzIGEgcGVyc2lzdGVudCBjb25uZWN0 aW9uIHRvIHRoZSBiYWNrZW5kLi4uDQoNCg== From nobody Mon Jun 12 11:30:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08363129572 for ; Mon, 12 Jun 2017 11:30:38 -0700 (PDT) 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=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 ZlVL4qnsr0oo for ; Mon, 12 Jun 2017 11:30:35 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 C4470129548 for ; Mon, 12 Jun 2017 11:30:35 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id t7so727464yba.3 for ; Mon, 12 Jun 2017 11:30:35 -0700 (PDT) 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=C0ZcE+/6BbAhGzX6bvYb7k8zaTFYoxoYRUui920UqfY=; b=oFTtmTQL4Bz8cff3GLJrTPwFYD/EMzsdMyKcwBOoaD13lxc/MCfWYpxsa+PlO9oF+R LwJhfMF/8lgXIe4cN+wVgiHorVXVNicwc6uuqTtou6xZ2FWAc1qM2NPUdff2lrzrllba wVOZ4ERePI75w3MVQx0ugiAnOeVgvQeoqD+KX3beY13jt4nuvLQHJV7e6Ejm5b/n/ur8 3E1rt6mVLUbak6WBIzG84FjmWPlL4wN8Mr9LLTRx8XlCLFrzvOhJisjyOeE1ud4YQpJL PF8wtMToFS0pBkF/5lLhE6xm7OhSuxlbBHTffhR4YAA/+P/bhQwVmKtIL7vMrHEbCmON foXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=C0ZcE+/6BbAhGzX6bvYb7k8zaTFYoxoYRUui920UqfY=; b=S3RoDjOvBJ3gC/grTwyHzm/of2MFrt+8vFyz1tUiY6iPXUSRLA27MY4xfVPoh7mfut VCoKwscEino4IMh60cU0wZM9s0MQUdrO/n8BdrpI1LF96AAhTu7/5kcVP0Ne6lcJHjXb yELATR5XUplib0/tzugyZJj/Otd5e8jvrI4Ez/IAUVOM8tH+Zl7/T3cZkyOcflrCEKdD PTEA9I2EBGFeYMLcNNjluGQtq2be1hTm5cq4sn6y+DgZ7PAEXoGqny3vM0s31pZ6I5bF ulLiYSrFvbwi5/UtipICYiclYy+7h6w4Ln8EjYdtOSkpk44bFZaUczXhGjgGJSqcGskG Hpsw== X-Gm-Message-State: AKS2vOy8vHzRoHJlm+VNruHZDe5u37G0WEAVg51AxU839/Ic0jJFk77A lyY8KPmWFb40ERvbI0zx0fCXXOV0r13d X-Received: by 10.37.68.214 with SMTP id r205mr266560yba.34.1497292234200; Mon, 12 Jun 2017 11:30:34 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.93.70 with HTTP; Mon, 12 Jun 2017 11:30:33 -0700 (PDT) In-Reply-To: <2e8816cf734e4bb78d36302c6910a82d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2e8816cf734e4bb78d36302c6910a82d@usma1ex-dag1mb1.msg.corp.akamai.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 12 Jun 2017 11:30:33 -0700 Message-ID: To: "Salz, Rich" Cc: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113f4d1abeb12a0551c783f7" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2017 18:30:38 -0000 --001a113f4d1abeb12a0551c783f7 Content-Type: text/plain; charset="UTF-8" On Mon, Jun 12, 2017 at 11:19 AM, Salz, Rich wrote: > > The one case here where I'd really argue for a "MUST" is middle-boxes > like CDNs. The concern I have is if someone has an application that uses > throttling or is vulnerable to a resource-exhaustion problem and goes and > puts a CDN in front of it, it's not obvious that enabling TLS 1.3 could > open them to a new kind of DOS attack. > > A CDN is not a middle box. It *is* origin as far as the end-users are > concerned, because of the business relationship between the CDN and the > content provider. Or, if you don't like that reasoning, then it's not a > middlebox as the IETF uses the term. > > If the intermediary is vulnerable to the resource attacks, that's the > intermediary's issue. > [ Browser ] <----> [ CDN ] <----> [ Origin ] Sorry - I'm not trying to be inflammatory here, it's just a descriptive term. All I mean is that the CDN is a box in the middle, as in that diagram. Here's what I imagine: * Operator A operates the origin, and they incorporate throttling as a routine security feature. * Operator B operates the CDN, and they offer TLS 1.3 as a feature, without replay protection. * Customer enables TLS 1.3 on the CDN, because they want the speed benefit. Seems totally reasonable! * If the CDN caches the requests, then the customer is now vulnerable to a new cache-analysis vulnerability. * If the CDN doesn't cache the requests, then the customer is now vulnerable to a new DOS vulnerability, in that the origin can be tipped over or locked out via the throttling. In this setup I say middle-box because the CDN is proxying requests. The latter problem here is created for the origin; but by the CDN. It's a real awful externality; because the CDN has a lot of incentive not to invest in real replay protection and hand-wave the issue away. That's my real core interoperability concern. > We've already seen CDNs enable TLS 1.3 with unintentionally broken 0-RTT > mitigations, so that's clear evidence that the existing guidance isn't > sufficient. I think it would help manage the interoperability risks if we > can point out to their customers that the configuration is unambiguously > broken. Or at least, it helps to flag it as a security issue, which makes > it more likely to get fixed. Absent this, the operators of "backend" > applications would have to live with risk that is created by the upstream > CDN providers for their own convenience. That seems like a really bad > interoperability set up. > > I agree with this. Which is why I prefer separate streams for early data, > and some kind of signaling to the content provider that is clear and > unambiguous. I don't know how to do that when, say, the intermediary/CDN > has a persistent connection to the backend... > That doesn't seem to be what some have deployed in the experimental deployments. There seems to be remarkably little traction for the separate streams. -- Colm --001a113f4d1abeb12a0551c783f7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 12, 2017 at 11:19 AM, Salz, Rich <rsalz@akamai= .com> wrote:
> The one case = here where I'd really argue for a "MUST" is middle-boxes like= CDNs. The concern I have is if someone has an application that uses thrott= ling or is vulnerable to a resource-exhaustion problem and goes and puts a = CDN in front of it, it's not obvious that enabling TLS 1.3 could open t= hem to a new kind of DOS attack.=C2=A0

A CDN is not a middle box.=C2=A0 It *is* origin as far as the end-us= ers are concerned, because of the business relationship between the CDN and= the content provider.=C2=A0 Or, if you don't like that reasoning, then= it's not a middlebox as the IETF uses the term.

If the intermediary is vulnerable to the resource attacks, that's the i= ntermediary's issue.

[ Browser ] &l= t;----> [ CDN ] <----> [ Origin ]=C2=A0

S= orry - I'm not trying to be inflammatory here, it's just a descript= ive term. All I mean is that the CDN is a box in the middle, as in that dia= gram.=C2=A0 Here's what I imagine:

* Operator = A operates the origin, and they incorporate throttling as a routine securit= y feature.=C2=A0
* Operator B operates the CDN, and they offer TL= S 1.3 as a feature, without replay protection.
* Customer enables= TLS 1.3 on the CDN, because they want the speed benefit. Seems totally rea= sonable!
* If the CDN caches the requests, then the customer is n= ow vulnerable to a new cache-analysis vulnerability.
* If the CDN= doesn't cache the requests, then the customer is now vulnerable to a n= ew DOS vulnerability, in that the origin can be tipped over or locked out v= ia the throttling.

In this setup I say middle-box = because the CDN is proxying requests. The latter problem here is created fo= r the origin; but by the CDN. It's a real awful externality; because th= e CDN has a lot of incentive not to invest in real replay protection and ha= nd-wave the issue away. That's my real core interoperability concern.= =C2=A0

> We've already seen CDNs enable TLS 1.3 with unintentionally broken= 0-RTT mitigations, so that's clear evidence that the existing guidance= isn't sufficient. I think it would help manage the interoperability ri= sks if we can point out to their customers that the configuration is unambi= guously broken. Or at least, it helps to flag it as a security issue, which= makes it more likely to get fixed. Absent this, the operators of "bac= kend" applications would have to live with risk that is created by the= upstream CDN providers for their own convenience. That seems like a really= bad interoperability set up. =C2=A0

I agree with this.=C2=A0 Which is why I prefer separate streams for = early data, and some kind of signaling to the content provider that is clea= r and unambiguous.=C2=A0 I don't know how to do that when, say, the int= ermediary/CDN has a persistent connection to the backend...

That doesn't seem to be what some have deployed in= the experimental deployments. There seems to be remarkably little traction= for the separate streams.=C2=A0

--
Colm
--001a113f4d1abeb12a0551c783f7-- From nobody Mon Jun 12 11:59:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53292129A96 for ; Mon, 12 Jun 2017 11:59:09 -0700 (PDT) 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 89F975IvSMxc for ; Mon, 12 Jun 2017 11:59:07 -0700 (PDT) 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 B220E129789 for ; Mon, 12 Jun 2017 11:59:07 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id 63so39825590ywr.0 for ; Mon, 12 Jun 2017 11:59:07 -0700 (PDT) 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=l5qRuPyyuDyCiaCf86JeAzo5JeycQj4MWPH2Lra812M=; b=1dpNwAngNqOLLVKMX1eXAo+9Jrh+FcUN6uqiX1qe9c+sRkxoSsIsfqqozg/av9oi/+ 4wKMFJiH9YbMU+qWIEjzxCh+4UZdHje9Y82uEx0KgDqwXCWMTMf7ujBb3K4zbAVjYPeo P/RmeR3apAb7+O1XK+4Ehu68VH5RfauirJQoBh0T2D0Z5RsKtZtB3XLnM/HB+ruhcCtm bAeVUzaDKkEcCv9vHy0NsfkGJveDeJBPX2wmU65ukwqo200q/nBhO15/GaiiTzX4cs3Q JxX/ae/uTpqQZVmj3pjGqMIx4Z1OAT8oRYj50CKtQb8QevPaFsJCLDI+75LhCkdJetUo 9fVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=l5qRuPyyuDyCiaCf86JeAzo5JeycQj4MWPH2Lra812M=; b=RrWagqHpX/qLhUm0cqKJjNKov/KtY0TG8ajJEsQwOsZz5YorCApI3JId835TIdOLWJ Mi0+V80kbsLIyrGgCSF2EGrakMJS4Q5hTWd/xpVsK6z8Cl2CgIRWRA9oRTcnPbaQqPpT ZfpLCtbtP29UZBu58eGXIsVMpSY/31zZtJE+sO04B3Ns1We9WKn+JLq/gfqIU6CyKujZ bDhTxv2Hh7/xum/QOX8c+BALAWtDGg764V55OBHdjnhjvtrhd5T7TDJcI5rBSE1x0fk6 OYcLDuM5Ati0q4snReW9FwiSqO+onLizkHVXy0zcvL8Onw9uN0UTQs9/xbBKeqFQYCuf vu6A== X-Gm-Message-State: AKS2vOxWG2OVjL2e1RvAUyp919i8nOaABt+sT9DsvcXnHH5/FWTEwUDp gv1kpViAynb6NX9cIO83+lXjvrBiWD9v X-Received: by 10.129.50.209 with SMTP id y200mr320374ywy.241.1497293946241; Mon, 12 Jun 2017 11:59:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.93.70 with HTTP; Mon, 12 Jun 2017 11:59:05 -0700 (PDT) In-Reply-To: <2e8816cf734e4bb78d36302c6910a82d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2e8816cf734e4bb78d36302c6910a82d@usma1ex-dag1mb1.msg.corp.akamai.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 12 Jun 2017 11:59:05 -0700 Message-ID: To: "Salz, Rich" Cc: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11408720ca90970551c7e94e" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 12 Jun 2017 18:59:09 -0000 --001a11408720ca90970551c7e94e Content-Type: text/plain; charset="UTF-8" On Mon, Jun 12, 2017 at 11:19 AM, Salz, Rich wrote: > I agree with this. Which is why I prefer separate streams for early data, > and some kind of signaling to the content provider that is clear and > unambiguous. I don't know how to do that when, say, the intermediary/CDN > has a persistent connection to the backend... > I've given this some thought, and I think it might be unworkable to have some kind of end-to-end 0-RTT. A simple example is that a CDN might want to make a slightly different request, with extra headers, towards the origin than the request that came in from the browser. For instance, the CDN might add an If-None-Match: or an If-Modified-Since. But those may not fit within the 0-RTT size limit. It gets really complicated across layering boundaries to have the CDN only accept 0-RTT if the origin also does, and if the request towards the origin will also fit, and so on. I think the CDN would have to defer accepting the 0-RTT from the browser until the origin accepted the 0-RTT from the origin; which defeats a lot of the intended speed/throughput benefit. Through this I've come to the conclusion that separate streams create more problems than they solve, and robust replay mitigation is a better answer. -- Colm --001a11408720ca90970551c7e94e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Jun 12, 2017 at 11:19 AM, Salz, Rich <rsalz@akamai.com><= /span> wrote:
I agree with this.=C2=A0 Wh= ich is why I prefer separate streams for early data, and some kind of signa= ling to the content provider that is clear and unambiguous.=C2=A0 I don'= ;t know how to do that when, say, the intermediary/CDN has a persistent con= nection to the backend...

I've give= n this some thought, and I think it might be unworkable to have some kind o= f end-to-end 0-RTT. A simple example is that a CDN might want to make a sli= ghtly different request, with extra headers, towards the origin than the re= quest that came in from the browser. For instance, the CDN might add an If-= None-Match: or an If-Modified-Since. But those may not fit within the 0-RTT= size limit.=C2=A0

It gets really complicated acro= ss layering boundaries to have the CDN only accept 0-RTT if the origin also= does, and if the request towards the origin will also fit, and so on. I th= ink the CDN would have to defer accepting the 0-RTT from the browser until = the origin accepted the 0-RTT from the origin; which defeats a lot of the i= ntended speed/throughput benefit.=C2=A0

Thro= ugh this I've come to the conclusion that separate streams create more = problems than they solve, and robust replay mitigation is a better answer.= =C2=A0

--
Colm
--001a11408720ca90970551c7e94e-- From nobody Mon Jun 12 17:32:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A512128CF0 for ; Mon, 12 Jun 2017 17:32:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, URIBL_BLOCKED=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 GRnYqlvvnbXk for ; Mon, 12 Jun 2017 17:32:27 -0700 (PDT) Received: from mail-ot0-x22d.google.com (mail-ot0-x22d.google.com [IPv6:2607:f8b0:4003:c0f::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 5FD1312778E for ; Mon, 12 Jun 2017 17:32:24 -0700 (PDT) Received: by mail-ot0-x22d.google.com with SMTP id i31so77153250ota.3 for ; Mon, 12 Jun 2017 17:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=IzF7W6BS7T17r2RPl9rXEE/MBpdC3yRLyN4uIuBkcxQ=; b=Hhv4M0RgaIDKqjth7yQl9bmTFqBA4Uw0FriSSr0Ge9iM0OaWF7ebTCTtHOpIbnVDLk EoBlmQDu2+iDDsZWwy7Z4AzQQ4HPfdDTSlvQmaJFAB/a4Q05UGTM5rK2dDCa1VeIxaxO 6HJgIvqH1+Tgwz7J86rP/PFCl/X22wF1SJStaOHex3O9N9nG8BzsYjmdWZ2bOVOh9MSd WR/6SKxINpcahu2r2hnFz/cKkWBsHe/Qa9R6tPNUD1EOcpWc2bzHZhlr2uABb7RBhWMy 5x/FjoVed1G66DgScCUsnPHYlUdZiHJdJRmK/mJXQzYhdmwJWN0etjaJEpOXjowlLkX4 FuNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IzF7W6BS7T17r2RPl9rXEE/MBpdC3yRLyN4uIuBkcxQ=; b=bQKGI24cFtR+Er7lx1LlXxyM9KwLPE+4xxrskPCPIW5byzBxVPpqAv/W83QnQBc3hb TDcagadfhXRIFWbbPdrskIzmcg9s+A8JetVUuoylG4W3xa+p+mwb5aNYVSflnpZFI36p gb1wBc0YU66/dlG2JEhhLi2Vj7ozq+hjnWlxtOjEoMNwblt7yRaGq9I0zQr+eNTWlpri IZJBufZr54oXqBqpWTOuv3KEPerHd0hXhGzgUqR8qak8n7cjwFuFyZkIvxQNChPDF+7D DtJm41UhUgminI7mYvMTEQxlv7Hfx0GwxKULiVdd/LVpkR2//VaczkqSoD42EeCxP8mr PPzQ== X-Gm-Message-State: AODbwcCCKh/2OnL5JRQjpSQAln1wwBSfaKEyCXRg/qT8PlZeS7MTmbVh 7jG3G44H2tFVL0qsIeuEj9RmfcI/vA== X-Received: by 10.157.43.117 with SMTP id f50mr27392222otd.56.1497313943500; Mon, 12 Jun 2017 17:32:23 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Tue, 13 Jun 2017 00:32:12 +0000 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113eddccb83c790551cc91b3" Archived-At: Subject: [TLS] Exported Authenticators proposed updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 00:32:29 -0000 --001a113eddccb83c790551cc91b3 Content-Type: text/plain; charset="UTF-8" All, I've collected a few changes that help clarify some ambiguities brought up on the list and during implementation of the draft. These changes are laid out as the following PRs in Github: Restrict the Certificate type to standard X.509 certificates. https://github.com/grittygrease/tls-exported-authenticator/pull/20 Relax requirement for the certificate_request_context to be unique, clarify the benefits of doing so. https://github.com/grittygrease/tls-exported-authenticator/pull/18 Be more explicit about how signature schemes are chosen and supported. https://github.com/grittygrease/tls-exported-authenticator/pull/18 Modify handshake context to be asymmetrical with respect to client and server. https://github.com/grittygrease/tls-exported-authenticator/pull/15 Let me know if there are any objections. If there are no comments I'll merge the changes and publish a new draft. Nick --001a113eddccb83c790551cc91b3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
All,

I've collected a= few changes that help clarify some ambiguities brought up on the list and = during implementation of the draft. These changes are laid out as the follo= wing PRs in Github:

Restrict the Certificate type to standard X.509 = certificates.

Relax= requirement for the certificate_request_context to be unique, clarify the = benefits of doing so.
Be more explicit about how signa= ture schemes are chosen and supported.

Modi= fy handshake context to be asymmetrical with respect to client and server.<= br>

Let me know if ther= e are any objections. If there are no comments I'll merge the changes a= nd publish a new draft.

Nick
--001a113eddccb83c790551cc91b3-- From nobody Tue Jun 13 00:56:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C794C129B94 for ; Tue, 13 Jun 2017 00:56:19 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 tjUI9eS5SH-y for ; Tue, 13 Jun 2017 00:56:17 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3BE40126BF0 for ; Tue, 13 Jun 2017 00:56:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 21BB622343; Tue, 13 Jun 2017 10:56:15 +0300 (EEST) 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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id 9MvM0n49W_Hx; Tue, 13 Jun 2017 10:56:14 +0300 (EEST) 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 A635321C; Tue, 13 Jun 2017 10:56:14 +0300 (EEST) Date: Tue, 13 Jun 2017 10:56:09 +0300 From: Ilari Liusvaara To: Nick Sullivan Cc: "tls@ietf.org" Message-ID: <20170613075609.GA8983@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: Subject: Re: [TLS] Exported Authenticators proposed updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 07:56:20 -0000 On Tue, Jun 13, 2017 at 12:32:12AM +0000, Nick Sullivan wrote: > All, > > I've collected a few changes that help clarify some ambiguities brought up > on the list and during implementation of the draft. These changes are laid > out as the following PRs in Github: > > Restrict the Certificate type to standard X.509 certificates. > https://github.com/grittygrease/tls-exported-authenticator/pull/20 Supporting certificates that are not X.509 actually brings major complications in protocol like this. The TLS library must recognize those types in order to properly extract the key needed to verify the CertificateVerify. The type extension can't just be skipped. Also, for related reasons, when implementing client certificates in TLS library I am working on, I only implemented X.509, despite the library supporting authentication based on keys, and RPK being supported for server authentication. The reason for this was the pretty nasty interaction of certificate types with client certificates. > Relax requirement for the certificate_request_context to be unique, clarify > the benefits of doing so. > https://github.com/grittygrease/tls-exported-authenticator/pull/18 Might also note unpredictability. And then note what happens if uniqueness (replays of the same certificate) or unpredictability (pregenerating responses) fails. Neither seems catastrophic (unlike, say repeating a nonce in AEAD). After all, the certificate contexts in TLS 1.3 discuss unpredictability. > Be more explicit about how signature schemes are chosen and supported. > https://github.com/grittygrease/tls-exported-authenticator/pull/18 This seems to be only place where non-standard APIs are required from the TLS library itself (I don't think most TLS APIs that do have exporters and EMS indication have facility to obtain the list of algorithms supported). And the client side is supposed to have a call for obtaining the supported algorithms anyway. Why not always operate on TLS 1.3 semantics, regardless of transport version? Main implications would be always using PSS with RSA and not mixing ECDSA curves and hashes. -Ilari From nobody Tue Jun 13 01:29:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D553E129BCC for ; Tue, 13 Jun 2017 01:29:32 -0700 (PDT) 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 OWP25HPujmsD for ; Tue, 13 Jun 2017 01:29:31 -0700 (PDT) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::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 4487A129BC8 for ; Tue, 13 Jun 2017 01:29:31 -0700 (PDT) Received: by mail-yb0-x236.google.com with SMTP id 4so33478089ybl.1 for ; Tue, 13 Jun 2017 01:29:31 -0700 (PDT) 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=6cQbeR7I/bRziRk6YMmgmSZ5cIFrXbbgOAo3QyisUZQ=; b=heL24FbKEoqQKbdogneDPN2eozE5KNO3zvIzUzveUF2ehgHjS5RCFq96pDl2exPFiD ZNep58PUwU9L700xRkMNbyXGrDacOh0JM4qMwyvgsL4s67OB8tLnLAvyRelxGEb0L72I MmZ1giR1Pth7b78u1GLJRawVHDTa3EAXP37byW9kS14jNrU2PXcUBYhh8qE108jE8L7R se+SljFZUurcIYLlbwURnMN9p5/v75pFs9V0VwDfqqOE2fViJu454ehx5LF0/ViPgeCQ DAp1DAU4wYyFmiCj5a0Oz6EzqkslYbikSXyA1tI+La7F3A2/3j25XHksNX4gIQmJQpcW fJeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6cQbeR7I/bRziRk6YMmgmSZ5cIFrXbbgOAo3QyisUZQ=; b=FhpDnlkkF2ZC3UiP+ST4uwvbatH8dgvFPqK7HdZM5vw0Oo55AEQQrNs8s+myizH5nC +J7tjn3yQm2l86e3X2eeIm3On0cdcOEZBECGEcT+YeTC4z0H1QJ6Y1ixLmwxlZEJUUMd L13GXvpIYT67sGgRv0RMxw0HdiVVQAQ60TVFHr/arNaZ6KuN3NWjQ0vvidJa2WFhmKJ/ w929IwWyt1rVgPvLfp/YJ2UdrdD22ZXwnkIN1KpsgVcV9dVVb6wpGcUnAWt6DBI8NdkC /VANG7Tp/X1hnqr6VA+B1VkxODYjDmrSLJhDpWrQgG9ekOc7p2Nxs5NC/MbkYcYm1j8l yVWw== X-Gm-Message-State: AKS2vOxk7eU/gt1p+/kO1qQ73QRn+5bus8tTt+0U2B/S1g0jSoqimBzD FcAikdEdKUgpUXBJKjPMfEAH8liq2XL2GGFKMQ== X-Received: by 10.37.177.164 with SMTP id h36mr2278785ybj.15.1497342570211; Tue, 13 Jun 2017 01:29:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Tue, 13 Jun 2017 01:28:49 -0700 (PDT) From: Eric Rescorla Date: Tue, 13 Jun 2017 09:28:49 +0100 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045eaaa40171a70551d33c01" Archived-At: Subject: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 08:29:33 -0000 --f403045eaaa40171a70551d33c01 Content-Type: text/plain; charset="UTF-8" The current text says: 0-RTT data has very different security properties from data transmitted after a completed handshake: it can be replayed. Implementations SHOULD provide different functions for reading and writing 0-RTT data and data transmitted after the handshake, and SHOULD NOT automatically resend 0-RTT data if it is rejected by the server. I think the second piece of guidance (about automatic re-send) is still good but it seems like implementations are mostly converging on a single API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have a single API and OpenSSL's use of two APIs is an outlier. I don't think it's helpful to have a SHOULD that a lot of people violate, especially when this also indicates we don't have consensus on this SHOULD. I propose we remove this recommendation in favor of one which simply says that implementations should need applications to opt-in to 0-RTT. That would allow implementations to have either API. -Ekr --f403045eaaa40171a70551d33c01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
The current text says:

= =C2=A0 =C2=A00-RTT data has very different security properties from data
=C2=A0 =C2=A0transmitted after a completed handshake: it can be rep= layed.
=C2=A0 =C2=A0Implementations SHOULD provide different func= tions for reading and
=C2=A0 =C2=A0writing 0-RTT data and data tr= ansmitted after the handshake, and
=C2=A0 =C2=A0SHOULD NOT automa= tically resend 0-RTT data if it is rejected by the
=C2=A0 =C2=A0s= erver.

I think the second piece of guidance = (about automatic re-send) is still good but it seems like implementations a= re mostly converging on a single API. Of the implementations I know, NSS, B= oringSSL (I think), and Mint have a single API and OpenSSL's use of two= APIs is an outlier. I don't think it's helpful to have a SHOULD th= at a lot of people violate, especially when this also indicates we don'= t have consensus on this SHOULD.

I propose we remo= ve this recommendation in favor of one which simply says that implementatio= ns should need applications to opt-in to 0-RTT. That would allow implementa= tions to have either API.

-Ekr





--f403045eaaa40171a70551d33c01-- From nobody Tue Jun 13 03:59:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95A061316EC for ; Tue, 13 Jun 2017 03:58:54 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 WJsemCrgPy4i for ; Tue, 13 Jun 2017 03:58:51 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 93193131790 for ; Tue, 13 Jun 2017 03:54:17 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 84DF929CF2; Tue, 13 Jun 2017 13:54:14 +0300 (EEST) 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 T8CxS3FYXj06; Tue, 13 Jun 2017 13:54:14 +0300 (EEST) 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 3C45721C; Tue, 13 Jun 2017 13:54:14 +0300 (EEST) Date: Tue, 13 Jun 2017 13:54:09 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170613105409.GB8983@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: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 10:58:55 -0000 On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote: > The current text says: > > 0-RTT data has very different security properties from data > transmitted after a completed handshake: it can be replayed. > Implementations SHOULD provide different functions for reading and > writing 0-RTT data and data transmitted after the handshake, and > SHOULD NOT automatically resend 0-RTT data if it is rejected by the > server. > > I think the second piece of guidance (about automatic re-send) is still > good but it seems like implementations are mostly converging on a single > API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have > a single API and OpenSSL's use of two APIs is an outlier. I don't think > it's helpful to have a SHOULD that a lot of people violate, especially when > this also indicates we don't have consensus on this SHOULD. > > I propose we remove this recommendation in favor of one which simply says > that implementations should need applications to opt-in to 0-RTT. That > would allow implementations to have either API. I think it is VERY bad idea for TLS client library to do 0-RTT without application explicitly opting in to that (e.g., via setting a special setting, or using API call sequences that didn't work at all for n-RTT). Consider for example that: - The application starts by sending a POST request. - The application starts by sending a GET to confidential URL. Both cases lead to things possibly going very badly wrong if TLS library silently does 0-RTT. And both are kind of requests that might be written before TLS connection is fuly up. And if ALPN is included, there is always a possibility that the initial guess on protocol was wrong, and the data can't just be autoretransmitted, but TLS stack has to ask the application to roll back the state. The server side does not have as obvious failure modes if 0-RTT is enabled without application knowledge, but that does not mean such failure modes are not out there. -Ilari From nobody Tue Jun 13 04:04:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 874501315BB for ; Tue, 13 Jun 2017 04:04:37 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 qo1L6hRdVrHQ for ; Tue, 13 Jun 2017 04:04:35 -0700 (PDT) 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 055EC131556 for ; Tue, 13 Jun 2017 04:02:04 -0700 (PDT) Received: by mail-yw0-x233.google.com with SMTP id v7so30280912ywc.2 for ; Tue, 13 Jun 2017 04:02:03 -0700 (PDT) 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=aPtF/sYdeHmZFB0LePlKGKcaBKRlmJk0+NKyfq2FnJs=; b=0XD10h8uCAJXsKmJSZ90jzvx5ED+tkP3GzXhWJr+7975OeqYkPjKTuCRzVBmNJNKSP LkMknPzBMrxr3nx5FRHJRtOcYgkv2quaQr1Q2yYmadQKBVRikyekj327VsB0v67w5vYZ /Kacw1raxgTKBNglH21Kq/nXSWJB4Kr1HCaPhBvoD/3jbM/rBucBYS2/vJY7aGKmjcol CCwSb6ULhHL2tU4xGM6rdpHBUgXvBFbiVn0MwsDFrv2i0NA64WAe+ZiYK968mtUsfYpi qifvsjsckBuTpViC21Tqj8mroHuFqhNsdUVIvVhLBdtMrOki58aEe/zdG1VYWqeXttgA DDTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=aPtF/sYdeHmZFB0LePlKGKcaBKRlmJk0+NKyfq2FnJs=; b=Gxw0PSDaF3TP3CDFw0jiaqugXKj3W1xmjVZXyXu1pKRlFqLJS0mMxJtgHAT1uCTADm ZC3uONH7py0dEfd89F6Xm6TY4L3n5McPOUMP3egP5xJ82CpdjSRBkoBuptX3e+XRF3na iQMJ+qE2dJLcizmpSGvJqaqOjYFL1wuj5SFa+5j5gpDIFhSpZxIi+gIVuNq7vY/b5sD0 ryHKaPcC7PObL0OpLTUx/PW++zWBQxiRvkWWzeqWo+aSV/O6Dklg9siYIltIPcMYncsM NC0JHBwq9ZvOdUSYFmX3SQp/w3uVV0vraLPwIB3x2sY4HC5Kq+yI3WbJkb4qv2k1nvje vhDA== X-Gm-Message-State: AKS2vOx2Edt+kgFCL5Tx8pPLmJGv4X15e5G/qvameQbv8iZLSWSA5TIj p/68M+kT7MHVKJMRc9uOi607DlqSlTT0 X-Received: by 10.129.43.68 with SMTP id r65mr2544833ywr.24.1497351723191; Tue, 13 Jun 2017 04:02:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Tue, 13 Jun 2017 04:01:22 -0700 (PDT) In-Reply-To: <20170613105409.GB8983@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613105409.GB8983@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Tue, 13 Jun 2017 12:01:22 +0100 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1141e79890bd3d0551d55df8" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 11:04:37 -0000 --001a1141e79890bd3d0551d55df8 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 11:54 AM, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote: > > The current text says: > > > > 0-RTT data has very different security properties from data > > transmitted after a completed handshake: it can be replayed. > > Implementations SHOULD provide different functions for reading and > > writing 0-RTT data and data transmitted after the handshake, and > > SHOULD NOT automatically resend 0-RTT data if it is rejected by the > > server. > > > > I think the second piece of guidance (about automatic re-send) is still > > good but it seems like implementations are mostly converging on a single > > API. Of the implementations I know, NSS, BoringSSL (I think), and Mint > have > > a single API and OpenSSL's use of two APIs is an outlier. I don't think > > it's helpful to have a SHOULD that a lot of people violate, especially > when > > this also indicates we don't have consensus on this SHOULD. > > > > I propose we remove this recommendation in favor of one which simply says > > that implementations should need applications to opt-in to 0-RTT. That > > would allow implementations to have either API. > > I think it is VERY bad idea for TLS client library to do 0-RTT without > application explicitly opting in to that (e.g., via setting a special > setting, or using API call sequences that didn't work at all for > n-RTT). > I agree with this. I am suggesting that a setting rather than a separate API is a reasonable approach. -Ekr > > Consider for example that: > > - The application starts by sending a POST request. > - The application starts by sending a GET to confidential URL. > > Both cases lead to things possibly going very badly wrong if TLS > library silently does 0-RTT. And both are kind of requests that might > be written before TLS connection is fuly up. > > And if ALPN is included, there is always a possibility that the > initial guess on protocol was wrong, and the data can't just be > autoretransmitted, but TLS stack has to ask the application to > roll back the state. > > > The server side does not have as obvious failure modes if 0-RTT is > enabled without application knowledge, but that does not mean such > failure modes are not out there. > > > > -Ilari > --001a1141e79890bd3d0551d55df8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 13, 2017 at 11:54 AM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote: > The current text says:
>
>=C2=A0 =C2=A0 0-RTT data has very different security properties from da= ta
>=C2=A0 =C2=A0 transmitted after a completed handshake: it can be replay= ed.
>=C2=A0 =C2=A0 Implementations SHOULD provide different functions for re= ading and
>=C2=A0 =C2=A0 writing 0-RTT data and data transmitted after the handsha= ke, and
>=C2=A0 =C2=A0 SHOULD NOT automatically resend 0-RTT data if it is rejec= ted by the
>=C2=A0 =C2=A0 server.
>
> I think the second piece of guidance (about automatic re-send) is stil= l
> good but it seems like implementations are mostly converging on a sing= le
> API. Of the implementations I know, NSS, BoringSSL (I think), and Mint= have
> a single API and OpenSSL's use of two APIs is an outlier. I don= 9;t think
> it's helpful to have a SHOULD that a lot of people violate, especi= ally when
> this also indicates we don't have consensus on this SHOULD.
>
> I propose we remove this recommendation in favor of one which simply s= ays
> that implementations should need applications to opt-in to 0-RTT. That=
> would allow implementations to have either API.

I think it is VERY bad idea for TLS client library to do 0-RTT witho= ut
application explicitly opting in to that (e.g., via setting a special
setting, or using API call sequences that didn't work at all for
n-RTT).

I agree with this. I am suggest= ing that a setting rather than a separate API is a
reasonable app= roach.

-Ekr
=C2=A0

Consider for example that:

- The application starts by sending a POST request.
- The application starts by sending a GET to confidential URL.

Both cases lead to things possibly going very badly wrong if TLS
library silently does 0-RTT. And both are kind of requests that might
be written before TLS connection is fuly up.

And if ALPN is included, there is always a possibility that the
initial guess on protocol was wrong, and the data can't just be
autoretransmitted, but TLS stack has to ask the application to
roll back the state.


The server side does not have as obvious failure modes if 0-RTT is
enabled without application knowledge, but that does not mean such
failure modes are not out there.



-Ilari

--001a1141e79890bd3d0551d55df8-- From nobody Tue Jun 13 04:32:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E06D21316A9 for ; Tue, 13 Jun 2017 04:32:41 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 eyEAUB1QBnE3 for ; Tue, 13 Jun 2017 04:32:39 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 276DB131688 for ; Tue, 13 Jun 2017 04:32:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id A1BFA39390; Tue, 13 Jun 2017 14:32:37 +0300 (EEST) 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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id rlDsTOyvCprC; Tue, 13 Jun 2017 14:32:37 +0300 (EEST) 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 56A3F2313; Tue, 13 Jun 2017 14:32:37 +0300 (EEST) Date: Tue, 13 Jun 2017 14:32:32 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170613113232.GC8983@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: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 11:32:42 -0000 On Sun, Jun 11, 2017 at 04:18:03PM +0100, Eric Rescorla wrote: > Hi folks, > > We've had a phenomenal amount of discussion around 0-RTT anti-replay, > and based on my recent summary e-mails I think we generally agree > about the technical facts, so it's time to finalize the PR and land it > in the specification. > > > Here's what I propose to do: > > - Describe the attacks that Colm described. That was mainly five attacks, right? - 0-RTT without stateful anti-replay allows for very high number of replays, breaking rate limiting systems, even high-performance ones, resulting in an opening for DDoS attacks. - 0-RTT without stateful anti-replay allows for very high number of replays, allowing exploiting timing side channels for information leakage. Very few if any applications are engineered to mitigate or eliminate such side channels. - 0-RTT without global anti-replay allows leaking informtation from the 0-RTT data via cache timing attacks. HTTP GET URLs sent to CDNs are especially vulernable. - 0-RTT without global anti-replay allows non-idempotent actions contained in 0-RTT data to be repeated potentially lots of times. Abuse of HTTP GET for non-idempotent actions is fairly common. - 0-RTT allows easily reordering request with retransmission from the client. This can lead to various unexpected application behavior if possibilty of such reordering is not taken into account. "Eventially consistent" datastores are especially vulernable. > - Distinguish between replay and retransmission > > - Mandate (SHOULD-level) that servers do some sort of bounded > (at-most-N times) anti-replay mechanism and emphasize that > implementations that forbid replays entirely (only allowing > retransmission) are superior. I don't remember seeing any scheme that looks feasible to implement, and that could limit amount replays but not to one per "server". (Of course, definition of "server" might sometimes be tricky, e.g. 8 "servers" all running in the same virtual machine. Also, I think SHOULD is bit questionable when not following it is almost certain to lead to severe problems. > - Describe the stateless mechanism as a recommended behavior but not > as a substitute for the other mechanisms. As Martin Thomson has > pointed out, it's a nice pre-filter for either of these other > mechanisms. Basically, the strike register is unimplementatble without bounding the replay window first in time. But I don't think that should be represented as a stateless mechanism, merely as a way of limiting the resources used by the strike register. > - Clarify the behavior you need to get PFS. > > - Require (MUST) that clients only send and servers only accept "safe" > requests in 0-RTT, but allow implementations to determine what is > safe. Also: - Note that 0-RTT exporters are not safe for authentication unless the server does global anti-replay on 0-RTT. -Ilari From nobody Tue Jun 13 05:22:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0823612E6D7 for ; Tue, 13 Jun 2017 05:22:58 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 2VN2elzNUTUg for ; Tue, 13 Jun 2017 05:22:56 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 6326612E054 for ; Tue, 13 Jun 2017 05:22:56 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DCCX3E030535; Tue, 13 Jun 2017 13:22:54 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=7nsxnBqXbmb75ll3chPhurnnt1L+un5aGNXdrx1c+PQ=; b=We4e2vgyU33qm6cJxemIjF7sKPDndg8LIgU88WRe2Kj5SSQP6WwGlz71u7kISfRDeD2Y p0oIonFD0vnq5xHGPpRSoS68B/zq3fbeEMJY6629bTUenDuT6oXrIiYpJU71TiEG9EHl HBbp2BbOKjrljOFY5pjKNaXq87yWiiGjeUylEedIcJDK2U3mv1Atgy2afEB1EhGX2XLL LdZ4575LU1R8ysxpAQsu9ZTSgFx5DdYnilcO4jATOHZDMuASwOVS8Kx5sFxtuqrINFrl I/ACHhp81mht4FUYRfl2XvdeNgTcRpsuvIbmBc3l5dba3NqITL9TSyfScYgs29rg+fNI Ew== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2b1u93y6v0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 13:22:54 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DCL1YD000826; Tue, 13 Jun 2017 08:22:53 -0400 Received: from email.msg.corp.akamai.com ([172.27.123.30]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b0c3vq19q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 08:22:53 -0400 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.1263.5; Tue, 13 Jun 2017 05:22:51 -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.1263.000; Tue, 13 Jun 2017 08:22:51 -0400 From: "Salz, Rich" To: Eric Rescorla , "tls@ietf.org" Thread-Topic: [TLS] Separate APIs for 0-RTT Thread-Index: AQHS5B8012CGgXSQukyGYKx22w/cV6IisvIw Date: Tue, 13 Jun 2017 12:22:50 +0000 Message-ID: <0a4f3f85fa80423ea72d3eec4c7710aa@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.33.130] Content-Type: multipart/alternative; boundary="_000_0a4f3f85fa80423ea72d3eec4c7710aausma1exdag1mb1msgcorpak_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130218 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130216 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 12:22:58 -0000 --_000_0a4f3f85fa80423ea72d3eec4c7710aausma1exdag1mb1msgcorpak_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWljcm9zb2Z0IGFsc28gaGFzIGEgc2VwYXJhdGUgQVBJIGZvciAwUlRUIGRhdGEuICBJIHdvdWxk IGNoYXJhY3Rlcml6ZSB0aGluZ3MgYXMgdGhlIHR3byBtb3N0IHBvcHVsYXIgYnJvd3NlcnMgaGF2 ZSBzdGF0ZWQgdGhlaXIgaW50ZW50aW9uIHRvIGhhdmUgYSBzaW5nbGUgQVBJLCBhbmQgdGhlIHR3 byBtb3N0IHBvcHVsYXIgc3lzdGVtIGxpYnJhcmllcyBoYXZlIHR3by4gIE91dGxpZXIgaXMgY2xl YXJseSB3cm9uZy4NCg0KSSBhZ3JlZSB3ZSBkb27igJl0IGhhdmUgY29uc2Vuc3VzLCBidXQgZG8g bWFrZSBzdXJlIHRoYXQgYW55IHdvcmRpbmcgY2hhbmdlIGFjY29tbW9kYXRlcyB0aGUgZmFjdCB0 aGF0IHRoZSBzcGxpdCBpc27igJl0IGFsbC12ZXJzdXMtb25lLg0K --_000_0a4f3f85fa80423ea72d3eec4c7710aausma1exdag1mb1msgcorpak_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNv LXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGlu az0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPk1pY3Jvc29mdCBhbHNvIGhhcyBhIHNlcGFyYXRlIEFQSSBm b3IgMFJUVCBkYXRhLiZuYnNwOyBJIHdvdWxkIGNoYXJhY3Rlcml6ZSB0aGluZ3MgYXMgdGhlIHR3 byBtb3N0IHBvcHVsYXIgYnJvd3NlcnMgaGF2ZSBzdGF0ZWQgdGhlaXIgaW50ZW50aW9uIHRvIGhh dmUgYSBzaW5nbGUgQVBJLCBhbmQgdGhlIHR3bw0KIG1vc3QgcG9wdWxhciBzeXN0ZW0gbGlicmFy aWVzIGhhdmUgdHdvLiZuYnNwOyBPdXRsaWVyIGlzIGNsZWFybHkgd3JvbmcuPG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPkkgYWdyZWUgd2UgZG9u4oCZdCBoYXZlIGNvbnNlbnN1cywgYnV0IGRvIG1ha2Ugc3VyZSB0 aGF0IGFueSB3b3JkaW5nIGNoYW5nZSBhY2NvbW1vZGF0ZXMgdGhlIGZhY3QgdGhhdCB0aGUgc3Bs aXQgaXNu4oCZdCBhbGwtdmVyc3VzLW9uZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_0a4f3f85fa80423ea72d3eec4c7710aausma1exdag1mb1msgcorpak_-- From nobody Tue Jun 13 05:28:15 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AEC08131808 for ; Tue, 13 Jun 2017 05:28:13 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 5_H-3fCP0Dbf for ; Tue, 13 Jun 2017 05:28:12 -0700 (PDT) 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 8373013180A for ; Tue, 13 Jun 2017 05:28:11 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id 63so47899420ywr.0 for ; Tue, 13 Jun 2017 05:28:11 -0700 (PDT) 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=HBCUNJT7M1zn6eavzTy7m6hNLRc3GQP0+v1Hest0KCo=; b=T84lOtofILRMWN/aDLgJ25WJMSA8Lk8OYw3ylGZpbvxXas0OWKCx7ndfqWCYF+L4G8 XPRFIEAX/f13wfYR9kQX6mFQvv74YZkVsBnG9+YQE5P1eYFMRLZW/WVu7pQZxmGND0e6 DVG/wJmk0uRncpvEXHkkCEq4dkAYhkugMQmkUl8YRMSHITKhdjQ5UmL3OPV6MFOqduRb pzvwWGeGwhz9CQlSsDtHDwLPMJWYrKdLKJACInb3vJtpZZagmcjsQVRNWXZpsPPDk6Br xylgQ5HoDVD/eeRe7pZmjVXxXh3Afq/owYP0SvaDmopMpCHFn1EhTfYvQ+docNaHi7NV 2YVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=HBCUNJT7M1zn6eavzTy7m6hNLRc3GQP0+v1Hest0KCo=; b=MD5qV7u00bvtrRexKCOx9WO5/WvpOeCSJ7tZnu+A145Wz9CXYoBt9HzD8pd6BtcCV0 qitDql9mhLA4+fum6moyC5zauODe4n2PS5eJ36MjzFEkyg9hq+X0OFiZAgiR7zDNMqeT Wj6cmOI1E5oVNVVAcdFyC6703v/VTcqO8PbujMP+JVWB5vdZlN8ydan+pD/ag8GF7kxh /qnVUN+V7X39aD/LqdInNEIH9WiALjJ6A0CFM8xUFkR8shc0e5i01dTFSqEzsh8tc62C jEu7B7tAQbqZgQFzRbs9BS68wY5gCgM0Db0LL66l5zs3xEZe3tMxgnljnofWqdt5JRUd Qarg== X-Gm-Message-State: AKS2vOzrczR9tZM3JYOwnG9OU0qCPAwRD0wjtIxP/TSfQreYKzNC/qxj 9wblGAEfLs5M3aUQS84hGhRwsvTZl3Kg X-Received: by 10.129.43.68 with SMTP id r65mr2832470ywr.24.1497356890568; Tue, 13 Jun 2017 05:28:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Tue, 13 Jun 2017 05:27:29 -0700 (PDT) In-Reply-To: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Tue, 13 Jun 2017 13:27:29 +0100 Message-ID: To: "Salz, Rich" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1141e79890ad9e0551d69111" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 12:28:14 -0000 --001a1141e79890ad9e0551d69111 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich wrote: > Microsoft also has a separate API for 0RTT data. I would characterize > things as the two most popular browsers have stated their intention to ha= ve > a single API, and the two most popular system libraries have two. Outlie= r > is clearly wrong. > I did not know that about Microsoft. Thanks for the update. I take back "outlier" > I agree we don=E2=80=99t have consensus, but do make sure that any wordin= g change > accommodates the fact that the split isn=E2=80=99t all-versus-one. > I was intending to use wording that was neutral between the two options without any claims about popularity. Thanks, -Ekr --001a1141e79890ad9e0551d69111 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 13, 2017 at 1:22 PM, Salz, Rich <rsalz@akamai.com> wr= ote:

Microsoft also has a separate API for 0RTT data.=C2= =A0 I would characterize things as the two most popular browsers have state= d their intention to have a single API, and the two most popular system libraries have two.=C2=A0 Outlier is clearly wrong.


I did not know that ab= out Microsoft. Thanks for the update. I take back "outlier"
=

=C2=A0

I agree we don=E2=80=99t have consensus, but do mak= e sure that any wording change accommodates the fact that the split isn=E2= =80=99t all-versus-one.


I was intending to = use wording that was neutral between the two options without any claims abo= ut popularity.

Thanks,
-Ekr

--001a1141e79890ad9e0551d69111-- From nobody Tue Jun 13 07:23:48 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E68161242EA for ; Tue, 13 Jun 2017 07:23:46 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 uRJ4DMweu8ZI for ; Tue, 13 Jun 2017 07:23:39 -0700 (PDT) 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 BD93C131502 for ; Tue, 13 Jun 2017 07:22:54 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id 63so50401961ywr.0 for ; Tue, 13 Jun 2017 07:22:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ZqbdYOJn8dCVWY1TwbWi1v4smgbJBYlNAuled8qnxJo=; b=a4M0x9HGyiEN0i6iff5+vDZZPIluEuKaiI83x2iuqmQjtdNuF3TDlwTPisFP0ChbzK bCTN85vD7QFq2UcPnB/nXKxdGh5yej0ncCfkkfxwPRDSy/hORXR4NyG7Ntvvs0UW8wpU UZrLvqgQUyJYq75XlQXOzRsWdtx0UaUCZM0tcDx/2UIycam1Vk2+4nlnjKN2o5zObInI 12Z03GTzVo8MPBmALfUXtUa/wYMXwneovpUT/L6dc33LkkVidybSc7BqODWeicI/8fHJ 55RcB7jmZFqXc0vK7DWFo06rP3ND4D3t2Nn1fE0/0iRBEJQEGR1sjzli0GaEaHgR2c6S E5cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=ZqbdYOJn8dCVWY1TwbWi1v4smgbJBYlNAuled8qnxJo=; b=E7fky+25lc9/kPYxwp9lRL8pnMkZW2WNmINgBMdbrWew3GSM/GUIhnowYbmOTpfdXU UX7DUdZZrspfGI7fCBb9PgReD38NY8fqfpCNL+CijqQatXJNA4YiHjEYIj5L4arrVTL3 wdVRo9SAYOA3y13Rjfr/K9mnO8EnSqEMEv7unZwOV/aQQPfEmW1nvRR/veafmQZMFhth tYbWSuS1Y7yVAv/2gyW3KkJ5Dyrtgsvb7AdcSC4h3lAIups069GaWkq7h5VjJaoNAhXl x73pp6c83kdzO21r2OmQ9ZtcLdXoC4Ddb8LZNgX4c4cXCxkbcQONTtrGmkFizjqDsNkd h9yw== X-Gm-Message-State: AKS2vOx9aIMsbDJ/VZwgJV1X5Pp5oaB7TfSTrHaPolw/NH6EFbrIRjSd NWPhQDetQQVITI1zTM7SbOtfwDRgb5hR X-Received: by 10.129.105.67 with SMTP id e64mr3231236ywc.129.1497363773751; Tue, 13 Jun 2017 07:22:53 -0700 (PDT) MIME-Version: 1.0 References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> In-Reply-To: From: Steven Valdez Date: Tue, 13 Jun 2017 14:22:42 +0000 Message-ID: To: Eric Rescorla , "Salz, Rich" Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1149012ed67c620551d82b68" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 14:23:47 -0000 --001a1149012ed67c620551d82b68 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Confirming that BoringSSL is using a single API for early/regular data, since we ran into issues/complications with our implementation of dual APIs with our use cases. On Tue, Jun 13, 2017 at 8:28 AM Eric Rescorla wrote: > On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich wrote: > >> Microsoft also has a separate API for 0RTT data. I would characterize >> things as the two most popular browsers have stated their intention to h= ave >> a single API, and the two most popular system libraries have two. Outli= er >> is clearly wrong. >> > > I did not know that about Microsoft. Thanks for the update. I take back > "outlier" > > > >> I agree we don=E2=80=99t have consensus, but do make sure that any wordi= ng change >> accommodates the fact that the split isn=E2=80=99t all-versus-one. >> > > I was intending to use wording that was neutral between the two options > without any claims about popularity. > > Thanks, > -Ekr > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --001a1149012ed67c620551d82b68 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Confirming that BoringSSL is using a single API for early/= regular data, since we ran into issues/complications with our implementatio= n of dual APIs with our use cases.

On Tue, Jun 13, 2017 at 8:28 AM Eric Rescorla <ekr@rtfm.com> wrote:
On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich <= ;rsalz@akamai.com= > wrote:

Microsoft also has a separate API for 0RTT data.=C2= =A0 I would characterize things as the two most popular browsers have state= d their intention to have a single API, and the two most popular system libraries have two.=C2=A0 Outlier is clearly wrong.


I did n= ot know that about Microsoft. Thanks for the update. I take back "outl= ier"

=C2=A0

I agree we don=E2=80=99t have consensus, but do mak= e sure that any wording change accommodates the fact that the split isn=E2= =80=99t all-versus-one.

=

I was= intending to use wording that was neutral between the two options without = any claims about popularity.

Thanks,
-Ekr

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
--001a1149012ed67c620551d82b68-- From nobody Tue Jun 13 09:19:40 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 171B512E870 for ; Tue, 13 Jun 2017 09:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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, URIBL_BLOCKED=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 iBAzNkJhatcU for ; Tue, 13 Jun 2017 09:19:35 -0700 (PDT) Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03on0139.outbound.protection.outlook.com [104.47.42.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF2E4131B35 for ; Tue, 13 Jun 2017 09:12:14 -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=R2E/ct8nRRocgKYOMJM/z08bdLmGAeFvflO6EAmNJUI=; b=DTG0YrDZzCzIi0A9e4kJtMIx+KKFkb04Cz4QsvfA/S4G9HtY05RBTHky9E05MKz+/1EdONcb/8ztNaRtDm0921+JcYttSKAAcfWgUCRhg4CMG9w0vPXj9lPJIbvIX8kXym8YmTKjO7iCzOHrymZdult34IkgQQ4nQxRBcm2x64Y= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0105.namprd21.prod.outlook.com (10.161.141.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.0; Tue, 13 Jun 2017 16:12:13 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2d6d:96d3:f164:d70f]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2d6d:96d3:f164:d70f%15]) with mapi id 15.01.1199.000; Tue, 13 Jun 2017 16:12:13 +0000 From: Andrei Popov To: Eric Rescorla , "Salz, Rich" CC: "tls@ietf.org" Thread-Topic: [TLS] Separate APIs for 0-RTT Thread-Index: AQHS5B82VxUJW2RS/kmCucGOID4L7aIit00AgAABTICAAD1wkA== Date: Tue, 13 Jun 2017 16:12:13 +0000 Message-ID: References: <0a4f3f85fa80423ea72d3eec4c7710aa@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: authentication-results: spf=none (sender IP is ) smtp.mailfrom=Andrei.Popov@microsoft.com; x-originating-ip: [2001:4898:80e8:b::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0105; 7:3/0nddWukhtb+gue8uIWLc1Tq/E1SnMoQ04B/93LKaLvls5TUAFqWcFdTa83M9kLMrompYkV3Rg2yWmmZy2VzTCbgSgq1qrEb/df52/vW4vvyD03Q24PgHI6XMfo4Eo5w6UGoj3yf6WDNTqUjrC6wVRHQ/g9jZE27C4crpRjKJ8Onu26oDkU6Cg8oe2bgawy+k0lkmWuN9lOtWsZwOn18Ahqt0ZTx4NUHzZD3JFEpSYYfDRtums8tkdywy7bqkmAjXC1MUsWSjUfhCJd53KOkb8DCd2ehZzUbAb4VbtMaie/N781kviYLtDiHqCKdtzIyyP7P51JDolSgch0V84eWwmKihFsd3aHGOyYPyL3aFUwzN106pgX48fNAA3by3G6NBt01vn6F8bejtbc3eSpyaCGVJsQpM8YIRYTGrnel2gmIh1Op22ggExcSW/96TI0kKC12995evFx7XSqqemSCrbvWjmc8yoAeGd9ybeT/MqLRIv3VlwsFMvMH+D+9q3p7GQpGH88tcqvW2lzvvCpqVO50smrmOuqG32gW1+fk2BBo7qai11LTx6+bKR+7tGEiY341WvfrrezUJfIV156BIGMyy0uFYdN2JqS68j0TfZoEHuVHvkYmYoryAcRQFpKQWZOpASHVQeBvblKko54zN3M2sXh3Yc2R6/qZz1KhXBVMjVKdMFrkyyVr06IbzIYR9sfN55/pPDn+DsxoyP0c5OUs+NfTyC494/ohB1fGEprZHF9VHG4zYNLdQ4gbIFnBYFeEcIQGUQnyCK6OXPTxayX5l3ATm+s7VTHWBV1Cig2uafJ0451QrBxC4q8R4NH x-ms-office365-filtering-correlation-id: 4386c3dd-28e9-4190-efc3-08d4b276f3d5 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR21MB0105; x-ms-traffictypediagnostic: DM2PR21MB0105: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(100000703101)(100105400095)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123558100)(201703131423075)(201703061421075)(201703161042150)(20161123564025)(20161123555025)(20161123560025)(6072148)(6042181)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0105; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0105; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(24454002)(377454003)(51914003)(189002)(72206003)(790700001)(6436002)(97736004)(53936002)(19609705001)(3280700002)(86362001)(10090500001)(68736007)(101416001)(54356999)(76176999)(50986999)(498600001)(4326008)(6246003)(14454004)(53546009)(10290500003)(229853002)(6116002)(5005710100001)(86612001)(25786009)(38730400002)(106356001)(6306002)(55016002)(54896002)(6506006)(189998001)(3660700001)(81166006)(105586002)(5250100002)(7736002)(2950100002)(236005)(8676002)(74316002)(102836003)(81156014)(5660300001)(33656002)(2900100001)(7696004)(2906002)(8990500004)(8936002)(99286003)(9686003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0105; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM2PR21MB00916718A71749E5D2CB19C38CC20DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2017 16:12:13.1810 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0105 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 16:19:38 -0000 --_000_DM2PR21MB00916718A71749E5D2CB19C38CC20DM2PR21MB0091namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Q29ycmVjdCwgSeKAmW0gcGxhbm5pbmcgYSBzZXBhcmF0ZSBBUEkgc3VyZmFjZSBmb3IgMC1SVFQs IGFzIE9wZW5TU0wgZGlkLg0KDQpXUlQgUkZDIGxhbmd1YWdlLCBwZXJoYXBzIGEgcmVhc29uYWJs ZSBjb21wcm9taXNlIHdvdWxkIGJlIHRvIHNheSB0aGF0IGEgVExTIGltcGxlbWVudGF0aW9uIFNI T1VMRCBvbmx5IGVuYWJsZSAwLVJUVCBhcHBsaWNhdGlvbiBkYXRhIHVwb24gZXhwbGljaXQgb3B0 LWluIGJ5IHRoZSBhcHBsaWNhdGlvbj8NCg0KVGhpcyBpcyBtb3JlIGZsZXhpYmxlIGFuZCBtYXkg aW52b2x2ZSBzZXBhcmF0ZSBBUElzLCBuZXcgb2ZmLWJ5LWRlZmF1bHQgZmxhZ3MgaW4gdGhlIGV4 aXN0aW5nIEFQSVMsIHdoYXRldmVyIGVsc2UgbWFrZXMgc2Vuc2UgZm9yIGEgcGFydGljdWxhciBU TFMgaW1wbGVtZW50YXRpb27igKYNCg0KQ2hlZXJzLA0KDQpBbmRyZWkNCg0KRnJvbTogVExTIFtt YWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBFcmljIFJlc2NvcmxhDQpT ZW50OiBUdWVzZGF5LCBKdW5lIDEzLCAyMDE3IDU6MjcgQU0NClRvOiBTYWx6LCBSaWNoIDxyc2Fs ekBha2FtYWkuY29tPg0KQ2M6IHRsc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtUTFNdIFNlcGFy YXRlIEFQSXMgZm9yIDAtUlRUDQoNCk9uIFR1ZSwgSnVuIDEzLCAyMDE3IGF0IDE6MjIgUE0sIFNh bHosIFJpY2ggPHJzYWx6QGFrYW1haS5jb208bWFpbHRvOnJzYWx6QGFrYW1haS5jb20+PiB3cm90 ZToNCk1pY3Jvc29mdCBhbHNvIGhhcyBhIHNlcGFyYXRlIEFQSSBmb3IgMFJUVCBkYXRhLiAgSSB3 b3VsZCBjaGFyYWN0ZXJpemUgdGhpbmdzIGFzIHRoZSB0d28gbW9zdCBwb3B1bGFyIGJyb3dzZXJz IGhhdmUgc3RhdGVkIHRoZWlyIGludGVudGlvbiB0byBoYXZlIGEgc2luZ2xlIEFQSSwgYW5kIHRo ZSB0d28gbW9zdCBwb3B1bGFyIHN5c3RlbSBsaWJyYXJpZXMgaGF2ZSB0d28uICBPdXRsaWVyIGlz IGNsZWFybHkgd3JvbmcuDQoNCkkgZGlkIG5vdCBrbm93IHRoYXQgYWJvdXQgTWljcm9zb2Z0LiBU aGFua3MgZm9yIHRoZSB1cGRhdGUuIEkgdGFrZSBiYWNrICJvdXRsaWVyIg0KDQoNCkkgYWdyZWUg d2UgZG9u4oCZdCBoYXZlIGNvbnNlbnN1cywgYnV0IGRvIG1ha2Ugc3VyZSB0aGF0IGFueSB3b3Jk aW5nIGNoYW5nZSBhY2NvbW1vZGF0ZXMgdGhlIGZhY3QgdGhhdCB0aGUgc3BsaXQgaXNu4oCZdCBh bGwtdmVyc3VzLW9uZS4NCg0KSSB3YXMgaW50ZW5kaW5nIHRvIHVzZSB3b3JkaW5nIHRoYXQgd2Fz IG5ldXRyYWwgYmV0d2VlbiB0aGUgdHdvIG9wdGlvbnMgd2l0aG91dCBhbnkgY2xhaW1zIGFib3V0 IHBvcHVsYXJpdHkuDQoNClRoYW5rcywNCi1Fa3INCg0K --_000_DM2PR21MB00916718A71749E5D2CB19C38CC20DM2PR21MB0091namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1z b0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJw bGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25v cm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28t bWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21z by1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5z LXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxl LXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5D b3JyZWN0LCBJ4oCZbSBwbGFubmluZyBhIHNlcGFyYXRlIEFQSSBzdXJmYWNlIGZvciAwLVJUVCwg YXMgT3BlblNTTCBkaWQuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPldSVCBSRkMgbGFuZ3VhZ2Us IHBlcmhhcHMgYSByZWFzb25hYmxlIGNvbXByb21pc2Ugd291bGQgYmUgdG8gc2F5IHRoYXQgYSBU TFMgaW1wbGVtZW50YXRpb24gU0hPVUxEIG9ubHkgZW5hYmxlIDAtUlRUIGFwcGxpY2F0aW9uIGRh dGEgdXBvbiBleHBsaWNpdCBvcHQtaW4gYnkgdGhlIGFwcGxpY2F0aW9uPzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5UaGlzIGlzIG1vcmUgZmxleGlibGUgYW5kIG1heSBpbnZvbHZlIHNlcGFyYXRl IEFQSXMsIG5ldyBvZmYtYnktZGVmYXVsdCBmbGFncyBpbiB0aGUgZXhpc3RpbmcgQVBJUywgd2hh dGV2ZXIgZWxzZSBtYWtlcyBzZW5zZSBmb3IgYSBwYXJ0aWN1bGFyIFRMUyBpbXBsZW1lbnRhdGlv buKApjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DaGVlcnMsPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkFuZHJlaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gVExTIFttYWls dG86dGxzLWJvdW5jZXNAaWV0Zi5vcmddIDxiPk9uIEJlaGFsZiBPZg0KPC9iPkVyaWMgUmVzY29y bGE8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgSnVuZSAxMywgMjAxNyA1OjI3IEFNPGJyPg0K PGI+VG86PC9iPiBTYWx6LCBSaWNoICZsdDtyc2FsekBha2FtYWkuY29tJmd0Ozxicj4NCjxiPkNj OjwvYj4gdGxzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbVExTXSBTZXBhcmF0 ZSBBUElzIGZvciAwLVJUVDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5PbiBUdWUsIEp1biAxMywgMjAxNyBhdCAxOjIyIFBNLCBTYWx6LCBSaWNoICZsdDs8YSBo cmVmPSJtYWlsdG86cnNhbHpAYWthbWFpLmNvbSIgdGFyZ2V0PSJfYmxhbmsiPnJzYWx6QGFrYW1h aS5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJi b3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBp biAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+TWljcm9zb2Z0IGFsc28gaGFzIGEgc2VwYXJh dGUgQVBJIGZvciAwUlRUIGRhdGEuJm5ic3A7IEkgd291bGQgY2hhcmFjdGVyaXplIHRoaW5ncyBh cyB0aGUgdHdvIG1vc3QgcG9wdWxhciBicm93c2VycyBoYXZlIHN0YXRlZCB0aGVpciBpbnRlbnRp b24gdG8gaGF2ZSBhIHNpbmdsZSBBUEksIGFuZCB0aGUgdHdvIG1vc3QNCiBwb3B1bGFyIHN5c3Rl bSBsaWJyYXJpZXMgaGF2ZSB0d28uJm5ic3A7IE91dGxpZXIgaXMgY2xlYXJseSB3cm9uZy48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5JIGRpZCBub3Qga25vdyB0aGF0IGFib3V0IE1pY3Jvc29mdC4gVGhh bmtzIGZvciB0aGUgdXBkYXRlLiBJIHRha2UgYmFjayAmcXVvdDtvdXRsaWVyJnF1b3Q7PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21h cmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG8iPkkgYWdyZWUgd2UgZG9u4oCZdCBoYXZlIGNvbnNlbnN1cywgYnV0IGRv IG1ha2Ugc3VyZSB0aGF0IGFueSB3b3JkaW5nIGNoYW5nZSBhY2NvbW1vZGF0ZXMgdGhlIGZhY3Qg dGhhdCB0aGUgc3BsaXQgaXNu4oCZdCBhbGwtdmVyc3VzLW9uZS48bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SSB3YXMgaW50ZW5kaW5nIHRvIHVzZSB3b3JkaW5nIHRoYXQgd2FzIG5ldXRyYWwgYmV0d2Vl biB0aGUgdHdvIG9wdGlvbnMgd2l0aG91dCBhbnkgY2xhaW1zIGFib3V0IHBvcHVsYXJpdHkuPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoYW5r cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi1F a3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_DM2PR21MB00916718A71749E5D2CB19C38CC20DM2PR21MB0091namp_-- From nobody Tue Jun 13 09:31:51 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42FB1128DF2 for ; Tue, 13 Jun 2017 09:31:49 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 fq5jOmJbDNbr for ; Tue, 13 Jun 2017 09:31:47 -0700 (PDT) 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 BA9211318E4 for ; Tue, 13 Jun 2017 09:29:46 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id e142so45519957ywa.1 for ; Tue, 13 Jun 2017 09:29:46 -0700 (PDT) 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=XfpKnep1cNxHon9Sl1l9zB/CnUZ/xLu55SP+DUXi7tU=; b=QGHH00PLvBVsa7SgnLglKAh8ZMQjWFI4nTpIM4a6NSl6m+UlsiczizUqLJgc6BZWo1 dmrSmTUUmqYqA8deHilTwp1H6gbcrji+McKg5ogWQaWlROCrdBAjwGafPSAtPZWY0hpq Fzb7pDmooicmMnFvcZna7IbVcop+2IPVbEpUKG7j2ENqbjGIFv967ASnwq/VtD8Dzl9t AGPK88rp6It10e3xkCgMRxQmrmw9hXh3RaEoyq2knWjXbGOYqWwL4KYRHd478F45ZEjb 8O/D9tmdVLumm9I55qlVMzEiqVMaa4uuWUM3/AoK7Wj6QjzrIgACFzaQMIMq+JdQRG+E DueA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=XfpKnep1cNxHon9Sl1l9zB/CnUZ/xLu55SP+DUXi7tU=; b=NxgcWTadltw9u7V1tVidSBUIEgV66Nzqb4U0f7cwMnQLd8vUGSH7FUOpXZr5k9Kny8 Pj3Gnx3LjOpc70BOyD3NlwT9aicW8WE2BcTc8rnG0U00Cxiac2SBYhCzNo8paMTWsbeK EBlxI8pvpeDBBy0R4geXA4BtlHMCUTRUsibuC5ML9guVJVRXxMPk5gEhZTuXcKYRBTP5 TN0h5EE6cw5Uu1vsNulUFPNaD/4UssrsEapfaDzZZTzUvOY3C905YTu6UPyDbtVwW7u3 mprnMikmYiX/Z8E3AO8Cpb/DS2pc9pEvHf+TW1ipgdUQNjPeUIeEbpbhKcIugFkTDfVU 3LrQ== X-Gm-Message-State: AKS2vOzgdxCi0o9g4wpjUv7+Ayfq0o1pr5N5XV7Iggjyq0Z1fhJKFQcZ 9r1e+0yTAJCfcpU1i3vrKPBb7/gOw/NhWy0= X-Received: by 10.129.172.39 with SMTP id k39mr3896169ywh.74.1497371386051; Tue, 13 Jun 2017 09:29:46 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.144 with HTTP; Tue, 13 Jun 2017 09:29:05 -0700 (PDT) In-Reply-To: References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> From: Eric Rescorla Date: Tue, 13 Jun 2017 17:29:05 +0100 Message-ID: To: Andrei Popov Cc: "Salz, Rich" , "tls@ietf.org" Content-Type: multipart/alternative; boundary="f403045e56ac901f5f0551d9f12d" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 16:31:49 -0000 --f403045e56ac901f5f0551d9f12d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This would be fine with me. -Ekr On Tue, Jun 13, 2017 at 5:12 PM, Andrei Popov wrote: > Correct, I=E2=80=99m planning a separate API surface for 0-RTT, as OpenSS= L did. > > > > WRT RFC language, perhaps a reasonable compromise would be to say that a > TLS implementation SHOULD only enable 0-RTT application data upon explici= t > opt-in by the application? > > > > This is more flexible and may involve separate APIs, new off-by-default > flags in the existing APIS, whatever else makes sense for a particular TL= S > implementation=E2=80=A6 > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Eric Rescorla > *Sent:* Tuesday, June 13, 2017 5:27 AM > *To:* Salz, Rich > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Separate APIs for 0-RTT > > > > On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich wrote: > > Microsoft also has a separate API for 0RTT data. I would characterize > things as the two most popular browsers have stated their intention to ha= ve > a single API, and the two most popular system libraries have two. Outlie= r > is clearly wrong. > > > > I did not know that about Microsoft. Thanks for the update. I take back > "outlier" > > > > > > I agree we don=E2=80=99t have consensus, but do make sure that any wordin= g change > accommodates the fact that the split isn=E2=80=99t all-versus-one. > > > > I was intending to use wording that was neutral between the two options > without any claims about popularity. > > > > Thanks, > > -Ekr > > > --f403045e56ac901f5f0551d9f12d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This would be fine with me.

-Ekr
<= div>

On T= ue, Jun 13, 2017 at 5:12 PM, Andrei Popov <Andrei.Popov@microsoft= .com> wrote:

Correct, I=E2=80=99m planning a separate API surface= for 0-RTT, as OpenSSL did.

=C2=A0

WRT RFC language, perhaps a reasonable compromise wo= uld be to say that a TLS implementation SHOULD only enable 0-RTT applicatio= n data upon explicit opt-in by the application?

=C2=A0

This is more flexible and may involve separate APIs,= new off-by-default flags in the existing APIS, whatever else makes sense f= or a particular TLS implementation=E2=80=A6

=C2=A0

Cheers,

=C2=A0

Andrei

=C2=A0

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, June 13, 2017 5:27 AM
To: Salz, Rich <rsalz@akamai.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Separate APIs for 0-RTT

=C2=A0

On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich <rsalz@akamai.com> = wrote:

Microsoft also has a separate API for 0RTT data.=C2= =A0 I would characterize things as the two most popular browsers have state= d their intention to have a single API, and the two most popular system libraries have two.=C2=A0 Outlier is clearly wrong.<= u>

=C2=A0

I did not know that about Microsoft. Thanks for the = update. I take back "outlier"

=C2=A0

=C2=A0

I agree we don=E2=80=99t have consensus, but do make= sure that any wording change accommodates the fact that the split isn=E2= =80=99t all-versus-one.

=C2=A0

I was intending to use wording that was neutral betw= een the two options without any claims about popularity.

=C2=A0

Thanks,

-Ekr

=C2=A0


--f403045e56ac901f5f0551d9f12d-- From nobody Tue Jun 13 09:36:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A59B12EAE4 for ; Tue, 13 Jun 2017 09:36:35 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 HHuCRrZGQ-pY for ; Tue, 13 Jun 2017 09:36:31 -0700 (PDT) Received: from mail-it0-x233.google.com (mail-it0-x233.google.com [IPv6:2607:f8b0:4001:c0b::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 E326F12EAB8 for ; Tue, 13 Jun 2017 09:36:29 -0700 (PDT) Received: by mail-it0-x233.google.com with SMTP id m47so44172496iti.1 for ; Tue, 13 Jun 2017 09:36:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=7H+VcFzZJzdEL0IJy3OZ47d+mTIEs+SbN8HYRkiaQZo=; b=s2cr1mVKq048FOUe2c6h9qocENQkWZztswVIRgwyUKp04yVqIAxK9aWc5VZLEpN04F ea/p9GPZXJggB+Ha76LsuaBsNLHstlKI2mKDQD5DUqofmzguRyCyi1rXZeP5nLj2P+U3 CskTvX7zTCrZlQsW71IkJDXLjWFjxWZScsGa6GJr08dlJVkSXxSPdNtYPArU4uX6nncx OsCHz+tr4rVBSADeGuwRxdhV9vGm2yAndPyBrnBJqcA0HKHxMvyVLnEYfLqYkiEoAXXC IU3tqVXPfgfWgXX88ROCx+agaVTGmVoioRt/xmPfIDlvrjNxaExi4bzYysDE+KLgl4uP UOoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7H+VcFzZJzdEL0IJy3OZ47d+mTIEs+SbN8HYRkiaQZo=; b=ImtnD6e0tehXmymfqXVQY/BxvtM8iP1Loe61yOVjC/UA5MUfNIbcaoRn3CXzmWMPFV ynX7P7RL9a0yCeYn0rbgw2j9G9yeULO+iIjdONOrRSRmwDnnrk1REEl1PySJrGH30idF F0yyuO36jIwCINjG+wE8ROIjdwBorh0mJGp4L7xFisOacm2I50p1frjTxtyzb+PG74rH kgQ12AJZAnd2Jku5qq5VrYsQxDtOU06GZIzacmSji/JxTtf3hpklx5f0Qr4qpXj1wS7i a3l4Awku9mEoY4Pl5VFIssXkte5wXow/rZss84keGvWBnegjtKHpRDr61C883rcjYKPb VUAg== X-Gm-Message-State: AODbwcCCNc+x7VofgRsYLF+7Ntn3Tv92xq8iSFxFMyqnILD3/mnl4jCw GkkjGLRXoUho7nw6Pv3nOOH9+uxkMg== X-Received: by 10.36.121.22 with SMTP id z22mr18122150itc.59.1497371789254; Tue, 13 Jun 2017 09:36:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.50.228.175 with HTTP; Tue, 13 Jun 2017 09:36:28 -0700 (PDT) In-Reply-To: <20170613105409.GB8983@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613105409.GB8983@LK-Perkele-V2.elisa-laajakaista.fi> From: Loganaden Velvindron Date: Tue, 13 Jun 2017 20:36:28 +0400 Message-ID: To: Ilari Liusvaara Cc: Eric Rescorla , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 16:36:35 -0000 On Tue, Jun 13, 2017 at 2:54 PM, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 09:28:49AM +0100, Eric Rescorla wrote: >> The current text says: >> >> 0-RTT data has very different security properties from data >> transmitted after a completed handshake: it can be replayed. >> Implementations SHOULD provide different functions for reading and >> writing 0-RTT data and data transmitted after the handshake, and >> SHOULD NOT automatically resend 0-RTT data if it is rejected by the >> server. >> >> I think the second piece of guidance (about automatic re-send) is still >> good but it seems like implementations are mostly converging on a single >> API. Of the implementations I know, NSS, BoringSSL (I think), and Mint have >> a single API and OpenSSL's use of two APIs is an outlier. I don't think >> it's helpful to have a SHOULD that a lot of people violate, especially when >> this also indicates we don't have consensus on this SHOULD. >> >> I propose we remove this recommendation in favor of one which simply says >> that implementations should need applications to opt-in to 0-RTT. That >> would allow implementations to have either API. > > I think it is VERY bad idea for TLS client library to do 0-RTT without > application explicitly opting in to that (e.g., via setting a special > setting, or using API call sequences that didn't work at all for > n-RTT). > I also agree here. From nobody Tue Jun 13 09:49:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 346B013188A for ; Tue, 13 Jun 2017 09:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-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 01_9iq_MFVKE for ; Tue, 13 Jun 2017 09:49:34 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (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 822FD131878 for ; Tue, 13 Jun 2017 09:49:33 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.39,338,1493676000"; d="asc'?scan'208,217";a="228218938" Received: from unknown (HELO [128.93.83.153]) ([128.93.83.153]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Jun 2017 18:49:31 +0200 From: Benjamin Beurdouche Message-Id: <1F7401C9-B317-47A2-9D54-84D28F5F4A66@inria.fr> Content-Type: multipart/signed; boundary="Apple-Mail=_DAAA8323-78A8-4C36-A934-BB4ACA229E14"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Tue, 13 Jun 2017 18:49:30 +0200 In-Reply-To: Cc: Rich Salz , ML IETF TLS , Andrei Popov To: Eric Rescorla References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 16:49:36 -0000 --Apple-Mail=_DAAA8323-78A8-4C36-A934-BB4ACA229E14 Content-Type: multipart/alternative; boundary="Apple-Mail=_2A35361F-791F-4306-AF85-265C8590CE7D" --Apple-Mail=_2A35361F-791F-4306-AF85-265C8590CE7D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Please forgive me for this naive question, but is there a specific = incentive for using =E2=80=9CSHOULD=E2=80=9D instead of =E2=80=9CMUST" only enable 0-RTT application data upon explicit opt-in = by the application... My fear is that, even with RFC 2119 terminology, 0RTT will likely be the = cause of many problems in the future and that being extra careful here is important=E2=80=A6 :) Best, Benjamin > On Jun 13, 2017, at 6:12 PM, Andrei Popov = wrote: >=20 > Correct, I=E2=80=99m planning a separate API surface for 0-RTT, as = OpenSSL did. >=20 > WRT RFC language, perhaps a reasonable compromise would be to say that = a TLS implementation SHOULD only enable 0-RTT application data upon = explicit opt-in by the application? >=20 > This is more flexible and may involve separate APIs, new = off-by-default flags in the existing APIS, whatever else makes sense for = a particular TLS implementation=E2=80=A6 >=20 > Cheers, >=20 > Andrei --Apple-Mail=_2A35361F-791F-4306-AF85-265C8590CE7D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Please forgive me for this naive question, = but is there a specific incentive for using =E2=80=9CSHOULD=E2=80=9D = instead of
=E2=80=9CMUST" only enable 0-RTT = application data upon explicit opt-in by the application...
My fear is that, even with RFC 2119 terminology, 0RTT will = likely be the cause of many problems in the future
and that being extra careful here is important=E2=80=A6 = :)

Best,
Benjamin

On = Jun 13, 2017, at 6:12 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

Correct, I=E2=80=99m planning a separate API surface for = 0-RTT, as OpenSSL did.
 
WRT RFC language, perhaps a reasonable compromise would be to = say that a TLS implementation SHOULD only enable 0-RTT application data = upon explicit opt-in by the application?
 
This is more flexible and may involve = separate APIs, new off-by-default flags in the existing APIS, whatever = else makes sense for a particular TLS implementation=E2=80=A6
 
Cheers,
 
Andrei
= --Apple-Mail=_2A35361F-791F-4306-AF85-265C8590CE7D-- --Apple-Mail=_DAAA8323-78A8-4C36-A934-BB4ACA229E14 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZQBebAAoJEEPN0iORm/jl1MYH/i3YJgzbvK4clnoE7MUR5UHS IUU9L4WBKqvzswcaeROCRlkVGac0e9ULh7uH3wjEIRmACQErCK4eZgbyYO2nNPsV qZdRPeTgHh7/C6VLl4brgPHMQWs/xLAey8KGoWJ9H4JdPnr1VCucdLXb4CaBRaPj ffV3LWNTW9WZjSz4Y7oYkb2H0v6F7K4CqxSQAZZ68nNhI5t6kp3HV9PJlMWZ9z9g zYWlneICJCzldt+QgefgNcTMV0d6NNlK45KftQmKAOoqz7jK1R1QeXUMBma9S71Z mfzlGj6ZPY3va4KsrB2wrwo9LpwedtvNXStavfTcy3HEg9UGuvBZsLI8O1Elfx0= =WYm7 -----END PGP SIGNATURE----- --Apple-Mail=_DAAA8323-78A8-4C36-A934-BB4ACA229E14-- From nobody Tue Jun 13 10:10:48 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E609C129418 for ; Tue, 13 Jun 2017 10:10:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.02 X-Spam-Level: X-Spam-Status: No, score=-2.02 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, URIBL_BLOCKED=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 qETx8tFEsYv5 for ; Tue, 13 Jun 2017 10:10:42 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0124.outbound.protection.outlook.com [104.47.32.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D68A912940F for ; Tue, 13 Jun 2017 10:10:41 -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=8sFfY3GDy+FwmI26xX8NkcUBtfEcmGHdg1PGnoocJTM=; b=lNGAcv22IA242QikPTP5ytnbmkfykgnKHpC74vOD69kA6IoyiQcmNNAl8CAO1ekSygiHUn9478Mws1+GeGxyBn8FEvlUYKoyAY/XoBDTk88YtGSX94y6J5APqJFQ/I3xs8NgBLvKFCjAAMruCVfesdXE+yXVuYIdOrD2e3OUeTk= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0043.namprd21.prod.outlook.com (10.161.140.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.3; Tue, 13 Jun 2017 17:10:40 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2d6d:96d3:f164:d70f]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2d6d:96d3:f164:d70f%15]) with mapi id 15.01.1199.000; Tue, 13 Jun 2017 17:10:40 +0000 From: Andrei Popov To: Benjamin Beurdouche , Eric Rescorla CC: Rich Salz , ML IETF TLS Thread-Topic: [TLS] Separate APIs for 0-RTT Thread-Index: AQHS5B82VxUJW2RS/kmCucGOID4L7aIit00AgAABTICAAD1wkIAAC8UAgAAEgiA= Date: Tue, 13 Jun 2017 17:10:39 +0000 Message-ID: References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <1F7401C9-B317-47A2-9D54-84D28F5F4A66@inria.fr> In-Reply-To: <1F7401C9-B317-47A2-9D54-84D28F5F4A66@inria.fr> 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:b::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0043; 7:dwd3Vv2GyWsVar2R/mKUK20aIjbkt1mo7fvGY4r7ewJmEhn1k+lI0J+Dzs2f7fJEiNLTCOKh2SnyURL0woF+kX0LkKj2A8Zh5wIJtWpFGRBkuyPofCl+fvTifX6IhTHtrMQV+18EBOuZanXJdIlxhlfa1HBrtHBrntbI6+uZvIeuJgE2x+8XEhgh2jV/bXB6y65OejrqICQ8cdUYRw04iN4xv5T0OCCC188b1rR38K1S9TlfYK12l7hl6agCi0yHUjVeZ4bAtoRocpOG6GTMQjjbgpa6ZzZ7p8rjgsUoGz2yNCJKsIjNwUMlJsNtSiK1TPuS+DAsmm6K+11sSYpk7kRj93JCy999inxDEZ649Dg0NvPLNmvNv5mMgEpOdOFmLdQafRgKngTqZsqdJz0gDc14wfne7ILzLUKTIV0P6CRIJJBYdJmfHEFG7A5OIWndyXvEQ/JT2ciUowtEO9LEZ6Kbj6kyslphAvLtAamdhCAAnw6sWx+I/Kj/ue5YkCNVWULvFlIO/WdrwXySYRYclLvp9R9O1alSC+se4mJfpMvqRfcXn/kt5JknqoTIEkSDgHzp8eAC7uIvT2RkqkKodIB8y7mqrpPwcGHB77GW0mIc/bueOze05IobgzFgHT93XzaG3axYmejNAxsc6dtIEwR6TgkIz7Owm9TiMSOqDmrhhBpbfhuAudMh0B0TWtpsNbGd+AG1snQ3xXEmmFB34uwKqBFkulC3Dsny10dw6lpjGFoDBFFv+BIE1ySICb1UN5xsHQsmlpbCcUBqPt3rXWFCT0PWOI3uLW7wC68+JRsXlXGMB4JlX/hO+Wj4i+pu x-ld-processed: 72f988bf-86f1-41af-91ab-2d7cd011db47,ExtAddr x-ms-office365-filtering-correlation-id: 8fc7d087-d46a-4ce9-3708-08d4b27f1e19 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR21MB0043; x-ms-traffictypediagnostic: DM2PR21MB0043: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(100405760836317)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(100000703101)(100105400095)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123558100)(20161123564025)(20161123560025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0043; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0043; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39840400002)(39450400003)(39860400002)(39400400002)(39410400002)(39850400002)(377454003)(189002)(24454002)(199003)(6116002)(7696004)(10290500003)(53936002)(14454004)(86362001)(236005)(5250100002)(106356001)(33656002)(5005710100001)(3660700001)(3280700002)(5660300001)(105586002)(478600001)(102836003)(10090500001)(2900100001)(790700001)(2950100002)(229853002)(25786009)(2906002)(74316002)(50986999)(54356999)(76176999)(38730400002)(101416001)(68736007)(4326008)(53546009)(72206003)(6306002)(99286003)(93886004)(81166006)(8676002)(55016002)(86612001)(9686003)(97736004)(81156014)(6506006)(54906002)(6246003)(7736002)(189998001)(54896002)(8936002)(8990500004)(6436002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0043; H:DM2PR21MB0091.namprd21.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_DM2PR21MB0091980D836EF551F8A339058CC20DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2017 17:10:39.9660 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0043 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 17:10:46 -0000 --_000_DM2PR21MB0091980D836EF551F8A339058CC20DM2PR21MB0091namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgTXkgZmVhciBpcyB0aGF0LCBldmVuIHdpdGggUkZDIDIxMTkgdGVybWlub2xvZ3ksIDBS VFQgd2lsbCBsaWtlbHkgYmUgdGhlIGNhdXNlIG9mIG1hbnkgcHJvYmxlbXMgaW4gdGhlIGZ1dHVy ZQ0KICAqICAgYW5kIHRoYXQgYmVpbmcgZXh0cmEgY2FyZWZ1bCBoZXJlIGlzIGltcG9ydGFudOKA piA6KQ0KDQpJIGFncmVlIHdpdGggdGhpcyBhc3Nlc3NtZW50LiBBIE1VU1Qgd291bGQgY2VydGFp bmx5IHdvcmsgZm9yIG1lLiBUaGVyZSBhcmUgdHdvIHJlYXNvbnMgSSBzdWdnZXN0ZWQgU0hPVUxE Og0KDQogIDEuICBBIE1VU1Qgd291bGQgYmUgbm9uLWVuZm9yY2VhYmxlIChhIFRMUyBjbGllbnQg b3Igc2VydmVyIGNhbuKAmXQgZW5mb3JjZSB0aGUgdXNlIG9mIGEgcGFydGljdWxhciBBUEkgYnkg dGhlIHBlZXIpLg0KICAyLiAgVGhlcmXigJlzIGxhY2sgb2YgY29uc2Vuc3VzIG9uIHRoZSB0b3Bp YyBvZiAwUlRUIGFuZCBJ4oCZbSB0cnlpbmcgdG8gc3VnZ2VzdCBhIGNvbXByb21pc2Xwn5iKLg0K DQpDaGVlcnMsDQoNCkFuZHJlaQ0KDQpGcm9tOiBCZW5qYW1pbiBCZXVyZG91Y2hlIFttYWlsdG86 YmVuamFtaW4uYmV1cmRvdWNoZUBpbnJpYS5mcl0NClNlbnQ6IFR1ZXNkYXksIEp1bmUgMTMsIDIw MTcgOTo1MCBBTQ0KVG86IEVyaWMgUmVzY29ybGEgPGVrckBydGZtLmNvbT4NCkNjOiBSaWNoIFNh bHogPHJzYWx6QGFrYW1haS5jb20+OyBNTCBJRVRGIFRMUyA8dGxzQGlldGYub3JnPjsgQW5kcmVp IFBvcG92IDxBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbT4NClN1YmplY3Q6IFJlOiBbVExTXSBT ZXBhcmF0ZSBBUElzIGZvciAwLVJUVA0KDQpQbGVhc2UgZm9yZ2l2ZSBtZSBmb3IgdGhpcyBuYWl2 ZSBxdWVzdGlvbiwgYnV0IGlzIHRoZXJlIGEgc3BlY2lmaWMgaW5jZW50aXZlIGZvciB1c2luZyDi gJxTSE9VTETigJ0gaW5zdGVhZCBvZg0K4oCcTVVTVCIgb25seSBlbmFibGUgMC1SVFQgYXBwbGlj YXRpb24gZGF0YSB1cG9uIGV4cGxpY2l0IG9wdC1pbiBieSB0aGUgYXBwbGljYXRpb24uLi4NCk15 IGZlYXIgaXMgdGhhdCwgZXZlbiB3aXRoIFJGQyAyMTE5IHRlcm1pbm9sb2d5LCAwUlRUIHdpbGwg bGlrZWx5IGJlIHRoZSBjYXVzZSBvZiBtYW55IHByb2JsZW1zIGluIHRoZSBmdXR1cmUNCmFuZCB0 aGF0IGJlaW5nIGV4dHJhIGNhcmVmdWwgaGVyZSBpcyBpbXBvcnRhbnTigKYgOikNCg0KQmVzdCwN CkJlbmphbWluDQoNCk9uIEp1biAxMywgMjAxNywgYXQgNjoxMiBQTSwgQW5kcmVpIFBvcG92IDxB bmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTxtYWlsdG86QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5j b20+PiB3cm90ZToNCg0KQ29ycmVjdCwgSeKAmW0gcGxhbm5pbmcgYSBzZXBhcmF0ZSBBUEkgc3Vy ZmFjZSBmb3IgMC1SVFQsIGFzIE9wZW5TU0wgZGlkLg0KDQpXUlQgUkZDIGxhbmd1YWdlLCBwZXJo YXBzIGEgcmVhc29uYWJsZSBjb21wcm9taXNlIHdvdWxkIGJlIHRvIHNheSB0aGF0IGEgVExTIGlt cGxlbWVudGF0aW9uIFNIT1VMRCBvbmx5IGVuYWJsZSAwLVJUVCBhcHBsaWNhdGlvbiBkYXRhIHVw b24gZXhwbGljaXQgb3B0LWluIGJ5IHRoZSBhcHBsaWNhdGlvbj8NCg0KVGhpcyBpcyBtb3JlIGZs ZXhpYmxlIGFuZCBtYXkgaW52b2x2ZSBzZXBhcmF0ZSBBUElzLCBuZXcgb2ZmLWJ5LWRlZmF1bHQg ZmxhZ3MgaW4gdGhlIGV4aXN0aW5nIEFQSVMsIHdoYXRldmVyIGVsc2UgbWFrZXMgc2Vuc2UgZm9y IGEgcGFydGljdWxhciBUTFMgaW1wbGVtZW50YXRpb27igKYNCg0KQ2hlZXJzLA0KDQpBbmRyZWkN Cg== --_000_DM2PR21MB0091980D836EF551F8A339058CC20DM2PR21MB0091namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6NzUyMzU3ODgzOw0KCW1zby1saXN0LXR5cGU6aHlicmlkOw0KCW1zby1s aXN0LXRlbXBsYXRlLWlkczo2NzkxMDQyNzQgMjg0MzMxODgwIDY3Njk4NjkxIDY3Njk4NjkzIDY3 Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtc3RhcnQtYXQ6MDsNCgltc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxp c3QgbDA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJp ZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxl dmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3Qt aWQ6MTc1MDczNDUyNTsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6MjEzNDQzNTIwNCA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5 ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlzdCBsMTpsZXZl bDENCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9 DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpy aWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDE6bGV2ZWw0DQoJe21zby1sZXZl bC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDE6bGV2 ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1p bmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu O30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dl cjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwxOmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9 DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQot LT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4 dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3Rl IG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpl eHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+ DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIg dHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4t bGVmdDowaW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPk15IGZlYXIgaXMgdGhhdCwgZXZlbiB3 aXRoIFJGQyAyMTE5IHRlcm1pbm9sb2d5LCAwUlRUIHdpbGwgbGlrZWx5IGJlIHRoZSBjYXVzZSBv ZiBtYW55IHByb2JsZW1zIGluIHRoZSBmdXR1cmU8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJN c29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVs MSBsZm8xIj5hbmQgdGhhdCBiZWluZyBleHRyYSBjYXJlZnVsIGhlcmUgaXMgaW1wb3J0YW504oCm IDopPG86cD48L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWdyZWUgd2l0aCB0aGlzIGFzc2Vz c21lbnQuIEEgTVVTVCB3b3VsZCBjZXJ0YWlubHkgd29yayBmb3IgbWUuIFRoZXJlIGFyZSB0d28g cmVhc29ucyBJIHN1Z2dlc3RlZCBTSE9VTEQ6PG86cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1h cmdpbi10b3A6MGluIiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJh Z3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowaW47bXNvLWxpc3Q6bDEgbGV2ZWwxIGxmbzIiPkEg TVVTVCB3b3VsZCBiZSBub24tZW5mb3JjZWFibGUgKGEgVExTIGNsaWVudCBvciBzZXJ2ZXIgY2Fu 4oCZdCBlbmZvcmNlIHRoZSB1c2Ugb2YgYSBwYXJ0aWN1bGFyIEFQSSBieSB0aGUgcGVlcikuPG86 cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1s ZWZ0OjBpbjttc28tbGlzdDpsMSBsZXZlbDEgbGZvMiI+VGhlcmXigJlzIGxhY2sgb2YgY29uc2Vu c3VzIG9uIHRoZSB0b3BpYyBvZiAwUlRUIGFuZCBJ4oCZbSB0cnlpbmcgdG8gc3VnZ2VzdCBhIGNv bXByb21pc2U8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVv dDssc2Fucy1zZXJpZiI+JiMxMjg1MjI7PC9zcGFuPi48bzpwPjwvbzpwPjwvbGk+PC9vbD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmRyZWk8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZyb206PC9i PiBCZW5qYW1pbiBCZXVyZG91Y2hlIFttYWlsdG86YmVuamFtaW4uYmV1cmRvdWNoZUBpbnJpYS5m cl0NCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDEzLCAyMDE3IDk6NTAgQU08YnI+ DQo8Yj5Ubzo8L2I+IEVyaWMgUmVzY29ybGEgJmx0O2VrckBydGZtLmNvbSZndDs8YnI+DQo8Yj5D Yzo8L2I+IFJpY2ggU2FseiAmbHQ7cnNhbHpAYWthbWFpLmNvbSZndDs7IE1MIElFVEYgVExTICZs dDt0bHNAaWV0Zi5vcmcmZ3Q7OyBBbmRyZWkgUG9wb3YgJmx0O0FuZHJlaS5Qb3BvdkBtaWNyb3Nv ZnQuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1RMU10gU2VwYXJhdGUgQVBJcyBm b3IgMC1SVFQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Q bGVhc2UgZm9yZ2l2ZSBtZSBmb3IgdGhpcyBuYWl2ZSBxdWVzdGlvbiwgYnV0IGlzIHRoZXJlIGEg c3BlY2lmaWMgaW5jZW50aXZlIGZvciB1c2luZyDigJxTSE9VTETigJ0gaW5zdGVhZCBvZjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+4oCcTVVTVCZx dW90OyBvbmx5IGVuYWJsZSAwLVJUVCBhcHBsaWNhdGlvbiBkYXRhIHVwb24gZXhwbGljaXQgb3B0 LWluIGJ5IHRoZSBhcHBsaWNhdGlvbi4uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+TXkgZmVhciBpcyB0aGF0LCBldmVuIHdpdGggUkZDIDIxMTkg dGVybWlub2xvZ3ksIDBSVFQgd2lsbCBsaWtlbHkgYmUgdGhlIGNhdXNlIG9mIG1hbnkgcHJvYmxl bXMgaW4gdGhlIGZ1dHVyZTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+YW5kIHRoYXQgYmVpbmcgZXh0cmEgY2FyZWZ1bCBoZXJlIGlzIGltcG9ydGFu dOKApiA6KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5CZXN0LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QmVuamFtaW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gSnVuIDEzLCAyMDE3LCBhdCA2OjEyIFBNLCBBbmRyZWkgUG9wb3YgJmx0OzxhIGhy ZWY9Im1haWx0bzpBbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbSI+QW5kcmVpLlBvcG92QG1pY3Jv c29mdC5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkNvcnJlY3QsIEnigJltIHBsYW5uaW5nIGEgc2VwYXJhdGUgQVBJIHN1cmZh Y2UgZm9yIDAtUlRULCBhcyBPcGVuU1NMIGRpZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V1JUIFJGQyBsYW5ndWFnZSwgcGVyaGFwcyBhIHJl YXNvbmFibGUgY29tcHJvbWlzZSB3b3VsZCBiZSB0byBzYXkgdGhhdCBhIFRMUyBpbXBsZW1lbnRh dGlvbiBTSE9VTEQgb25seSBlbmFibGUgMC1SVFQgYXBwbGljYXRpb24gZGF0YSB1cG9uIGV4cGxp Y2l0IG9wdC1pbiBieSB0aGUgYXBwbGljYXRpb24/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoaXMgaXMgbW9yZSBmbGV4aWJsZSBhbmQgbWF5 IGludm9sdmUgc2VwYXJhdGUgQVBJcywgbmV3IG9mZi1ieS1kZWZhdWx0IGZsYWdzIGluIHRoZSBl eGlzdGluZyBBUElTLCB3aGF0ZXZlciBlbHNlIG1ha2VzIHNlbnNlIGZvciBhIHBhcnRpY3VsYXIg VExTIGltcGxlbWVudGF0aW9u4oCmPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kcmVpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_DM2PR21MB0091980D836EF551F8A339058CC20DM2PR21MB0091namp_-- From nobody Tue Jun 13 10:37:07 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6DF12940E for ; Tue, 13 Jun 2017 10:37:05 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 7GQo8fRgcYix for ; Tue, 13 Jun 2017 10:37:01 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 C0D361319F9 for ; Tue, 13 Jun 2017 10:36:59 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DHXj82018443; Tue, 13 Jun 2017 18:36:58 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=TmJHqgic6g81czEGAQ9U3anuzBlcL16lzkc5fVRc3IY=; b=VBCiKJEsdaqTWJga/ofVKNT488VTxNFoFJA9eULAWBMfZNWwHESyQRMgjGYBYLNEUq1i e3itbOuZhM3kC9Ku/i7TI0W0oCcgLnfrlMpqrVA8SC7fw0duPkZyTUrXNVKayTkW75eP YfP1DuTrychu7pYPMGzJLt/HG+N1ibOgtawn9CCSyrr2MVFlaCoSEkND2PE0pdDb3vID 7CUVI/FQBespvccV0n3EbFL6aGPEG/wbtl+7XPYefWf916+F5BRO5hMI2n1hC9wkcCON HN49LlVyTm2nbl8hO9Da/UmwwLQSd2wtmBfdiiM+6n7uQZ9kEIC07Jzl7LAImR5bQ0+f Dw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2b2javs4m4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 18:36:58 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DHa3TY019099; Tue, 13 Jun 2017 13:36:57 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b0c3uys34-1; Tue, 13 Jun 2017 13:36:57 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 7C91180052; Tue, 13 Jun 2017 11:36:56 -0600 (MDT) To: Eric Rescorla , Andrei Popov Cc: "tls@ietf.org" References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> From: Benjamin Kaduk Message-ID: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> Date: Tue, 13 Jun 2017 12:36:55 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9255461668080A4E7666530C" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130302 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130301 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 17:37:06 -0000 This is a multi-part message in MIME format. --------------9255461668080A4E7666530C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit That's fine with me as well, though I am now considering the question of having an API for the server application to know whether a given request was received over 0- or 1-RTT. -Ben On 06/13/2017 11:29 AM, Eric Rescorla wrote: > This would be fine with me. > > -Ekr > > > On Tue, Jun 13, 2017 at 5:12 PM, Andrei Popov > > wrote: > > Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL > did. > > > > WRT RFC language, perhaps a reasonable compromise would be to say > that a TLS implementation SHOULD only enable 0-RTT application > data upon explicit opt-in by the application? > > > > This is more flexible and may involve separate APIs, new > off-by-default flags in the existing APIS, whatever else makes > sense for a particular TLS implementation… > > > > Cheers, > > > > Andrei > > > > *From:* TLS [mailto:tls-bounces@ietf.org > ] *On Behalf Of *Eric Rescorla > *Sent:* Tuesday, June 13, 2017 5:27 AM > *To:* Salz, Rich > > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Separate APIs for 0-RTT > > > > On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich > wrote: > > Microsoft also has a separate API for 0RTT data. I would > characterize things as the two most popular browsers have > stated their intention to have a single API, and the two most > popular system libraries have two. Outlier is clearly wrong. > > > > I did not know that about Microsoft. Thanks for the update. I take > back "outlier" > > > > > > I agree we don’t have consensus, but do make sure that any > wording change accommodates the fact that the split isn’t > all-versus-one. > > > > I was intending to use wording that was neutral between the two > options without any claims about popularity. > > > > Thanks, > > -Ekr > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------9255461668080A4E7666530C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit That's fine with me as well, though I am now considering the question of having an API for the server application to know whether a given request was received over 0- or 1-RTT.

-Ben

On 06/13/2017 11:29 AM, Eric Rescorla wrote:
This would be fine with me.

-Ekr


On Tue, Jun 13, 2017 at 5:12 PM, Andrei Popov <Andrei.Popov@microsoft.com> wrote:

Correct, I’m planning a separate API surface for 0-RTT, as OpenSSL did.

 

WRT RFC language, perhaps a reasonable compromise would be to say that a TLS implementation SHOULD only enable 0-RTT application data upon explicit opt-in by the application?

 

This is more flexible and may involve separate APIs, new off-by-default flags in the existing APIS, whatever else makes sense for a particular TLS implementation…

 

Cheers,

 

Andrei

 

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Eric Rescorla
Sent: Tuesday, June 13, 2017 5:27 AM
To: Salz, Rich <rsalz@akamai.com>
Cc: tls@ietf.org
Subject: Re: [TLS] Separate APIs for 0-RTT

 

On Tue, Jun 13, 2017 at 1:22 PM, Salz, Rich <rsalz@akamai.com> wrote:

Microsoft also has a separate API for 0RTT data.  I would characterize things as the two most popular browsers have stated their intention to have a single API, and the two most popular system libraries have two.  Outlier is clearly wrong.

 

I did not know that about Microsoft. Thanks for the update. I take back "outlier"

 

 

I agree we don’t have consensus, but do make sure that any wording change accommodates the fact that the split isn’t all-versus-one.

 

I was intending to use wording that was neutral between the two options without any claims about popularity.

 

Thanks,

-Ekr

 




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

--------------9255461668080A4E7666530C-- From nobody Tue Jun 13 10:37:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 820F21319F3 for ; Tue, 13 Jun 2017 10:37:52 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 zJiAKYJ_D83F for ; Tue, 13 Jun 2017 10:37:50 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 075CA12940E for ; Tue, 13 Jun 2017 10:37:49 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 21B602A546; Tue, 13 Jun 2017 20:37:49 +0300 (EEST) 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 eVf2nzU4lCxs; Tue, 13 Jun 2017 20:37:48 +0300 (EEST) 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 E28AB21C; Tue, 13 Jun 2017 20:37:48 +0300 (EEST) Date: Tue, 13 Jun 2017 20:37:44 +0300 From: Ilari Liusvaara To: Andrei Popov Cc: Benjamin Beurdouche , Eric Rescorla , ML IETF TLS Message-ID: <20170613173744.GC12048@LK-Perkele-V2.elisa-laajakaista.fi> References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <1F7401C9-B317-47A2-9D54-84D28F5F4A66@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 17:37:52 -0000 On Tue, Jun 13, 2017 at 05:10:39PM +0000, Andrei Popov wrote: > * My fear is that, even with RFC 2119 terminology, 0RTT will likely be the cause of many problems in the future > * and that being extra careful here is important… :) > > I agree with this assessment. A MUST would certainly work for me. There are two reasons I suggested SHOULD: > > 1. A MUST would be non-enforceable (a TLS client or server can’t enforce the use of a particular API by the peer). I would say what the endpoint _itself_ does is more relevant than what the _peer_ does. I gave some examples of things going badly wrong if the application does not opt-in, especially at client side. And on server side, the requirement to only accept "safe" things for 0-RTT can't be done without opt-in. > 2. There’s lack of consensus on the topic of 0RTT and I’m trying to suggest a compromise😊. Not in all aspects of it. -Ilari From nobody Tue Jun 13 10:46:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E8777131991 for ; Tue, 13 Jun 2017 10:46:14 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] 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 ga085RIBWlWn for ; Tue, 13 Jun 2017 10:46:13 -0700 (PDT) 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 E95CA1270A0 for ; Tue, 13 Jun 2017 10:46:12 -0700 (PDT) Received: by mail-yw0-x230.google.com with SMTP id v7so38113646ywc.2 for ; Tue, 13 Jun 2017 10:46:12 -0700 (PDT) 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=Wn6TgP0QGk8lHPN2kKfPUcHEh8fhEvWeoHED7NAXjLQ=; b=RiJEjodaOan+5u6Cph/nojNkyWWeox9lG2eJ4fsChEN5fNzXYgK9DLtMGOx84+FcZW MUhAJmNFQx0eaODO3UWip6T8pGd/YAJDCF+RlBT1pNrPmwei1X2QVYBX1dmwE+BHjQhi EoH0PXgoTw+mVi+LAurJnpiBk7Rk7pr/vOcnCb52WVRyrM7qqr/OIhsyxjpL+DmnZg9P 7tLZfeKswZi0gmI5JGjm6gonmG7k5I7YTmnTv30XEOi0gsMOWIZZb2/FXjW/TCqgKTfX xoJD1PI/hOXJU4QLYFGpPhNPK/gLObNms607u+Sr4SPi2vSxbQMZKlFEOujQO/Ya8wSh 1WyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Wn6TgP0QGk8lHPN2kKfPUcHEh8fhEvWeoHED7NAXjLQ=; b=WXNeEuZg0apoR4lhMHufyzn0hjZ95e91sb3Nscrcb9mcCUPn+OFL9L1fS8ClsV0tDP U5E40+56Eh/jWoDH+XPw2A4N6Nl3swEukmrykrzLIKNBdCfPXi1OSezZP0wtn57IAMXK t0p+AAtQ17bW2dXjdN7hdr+4uti7OlBhM/dgPIfhuF/545VyFJVdYMNf+C/WvcPH7N9f qO3bFrLfgtDZze+KN4HetqXHGzUAHlwER6lRDmgHUk4jzWGibSQPBguf4bY71HaibKxH MVosbWAvD1HCUT7/wENeGWPqQSr1zR2kecXUK36brdshKPu91Knlh/iNHZMSseaTCWfd U49A== X-Gm-Message-State: AKS2vOxEZEJwX7KJqx7qY+gsosvMTBt0ml1IUbSjY1EiCmiOdbwmh48E nNg5zcm8/Iv2kyHJzdjE+Bsz5IKum6fp X-Received: by 10.129.50.209 with SMTP id y200mr4588178ywy.241.1497375972009; Tue, 13 Jun 2017 10:46:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.93.70 with HTTP; Tue, 13 Jun 2017 10:46:11 -0700 (PDT) In-Reply-To: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 13 Jun 2017 10:46:11 -0700 Message-ID: To: Benjamin Kaduk Cc: Eric Rescorla , Andrei Popov , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11408720e85d7a0551db0222" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 17:46:15 -0000 --001a11408720e85d7a0551db0222 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 10:36 AM, Benjamin Kaduk wrote: > That's fine with me as well, though I am now considering the question of > having an API for the server application to know whether a given request > was received over 0- or 1-RTT. > For s2n, I'm leaning towards recommending the opposite; signaling on the client side, if opt-in 0-RTT fails, but no signaling on the server side (though still opt-in). My reasoning is based on experience with that "X-" server-side header trick; it misleads people into what's going on in a way that leads to brokenness. The application people think they only have to de-dupe the 0-RTT sections, but that's not true. -- Colm --001a11408720e85d7a0551db0222 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Tue, Jun 13, 2017 at 10:36 AM, Benjamin Kaduk <= bkaduk@akamai.com> wrote:
=20 =20 =20
That's fine with me as well, though I am now considering the question of having an API for the server application to know whether a given request was received over 0- or 1-RTT.
=


For s2n, I'm leaning to= wards recommending the opposite; signaling on the client side, if opt-in 0-= RTT fails, but no signaling on the server side (though still opt-in). My re= asoning is based on experience with that "X-" server-side header = trick; it misleads people into what's going on in a way that leads to b= rokenness. The application people think they only have to de-dupe the 0-RTT= sections, but that's not true.=C2=A0

--
=
Colm
--001a11408720e85d7a0551db0222-- From nobody Tue Jun 13 11:04:28 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42F4F129457 for ; Tue, 13 Jun 2017 11:04:25 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 RDlec5BuA-_D for ; Tue, 13 Jun 2017 11:04:23 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 66E3E129464 for ; Tue, 13 Jun 2017 11:04:23 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DI4L4O015771; Tue, 13 Jun 2017 19:04:21 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=L0U8Bk8ObzO2s7PUHx/Gn+UB0s87+Y/VaHuBnSMU5RM=; b=XUmOaIgofs345aIAnEpMXFwfmOvJcmJ4QQzxEnKenmTqq9NvQ79WIklFXh9noJqkRMwM jX+u4AOiJEc++m3u5dNM+1A5dNYAM6b9sTSn7ztoS+aeeVYQAFd79ArNJBq9/xuC+xi3 FwTrWlzguihQbmyvqNh9ZiYtgEBcbX44Mpc7DSvDRa9i2C4LjbNo5VCBUr5WVooorQfT RrcqDuxySY28tT3wv+ACy6Rmz/ourMjiHRBlKJER6NpkLN8C4pyVrsNO1RFzm9R1bamA iS9F0RTQDPL1SXFB6snQDE2V+rWkZhvwpB7tPrZhD2dZcK0eC8oKZQFuWRWENQrun9r1 4Q== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050095.ppops.net-00190b01. with ESMTP id 2b2javs9ws-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 19:04:21 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DI16Ax019400; Tue, 13 Jun 2017 14:04:20 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b0c3vqt00-1; Tue, 13 Jun 2017 14:04:20 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id C40AA20069; Tue, 13 Jun 2017 12:04:19 -0600 (MDT) To: =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= Cc: Eric Rescorla , "tls@ietf.org" References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> From: Benjamin Kaduk Message-ID: Date: Tue, 13 Jun 2017 13:04:19 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A89820F635BCB5AE4A1C942C" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130310 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_08:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130310 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 18:04:25 -0000 This is a multi-part message in MIME format. --------------A89820F635BCB5AE4A1C942C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/13/2017 12:46 PM, Colm MacCárthaigh wrote: > > > On Tue, Jun 13, 2017 at 10:36 AM, Benjamin Kaduk > wrote: > > That's fine with me as well, though I am now considering the > question of having an API for the server application to know > whether a given request was received over 0- or 1-RTT. > > > > For s2n, I'm leaning towards recommending the opposite; signaling on > the client side, if opt-in 0-RTT fails, but no signaling on the server > side (though still opt-in). My reasoning is based on experience with > that "X-" server-side header trick; it misleads people into what's > going on in a way that leads to brokenness. The application people > think they only have to de-dupe the 0-RTT sections, but that's not true. > I have been operating under the impression that at least some application profiles for early data will require that certain application protocol requests (e.g., something like HTTP POST) must be rejected at the application layer as "not appropriate for 0-RTT data", which requires the application to know if the request was received over 0-RTT data. -Ben --------------A89820F635BCB5AE4A1C942C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/13/2017 12:46 PM, Colm MacCárthaigh wrote:


On Tue, Jun 13, 2017 at 10:36 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
That's fine with me as well, though I am now considering the question of having an API for the server application to know whether a given request was received over 0- or 1-RTT.


For s2n, I'm leaning towards recommending the opposite; signaling on the client side, if opt-in 0-RTT fails, but no signaling on the server side (though still opt-in). My reasoning is based on experience with that "X-" server-side header trick; it misleads people into what's going on in a way that leads to brokenness. The application people think they only have to de-dupe the 0-RTT sections, but that's not true. 


I have been operating under the impression that at least some application profiles for early data will require that certain application protocol requests (e.g., something like HTTP POST) must be rejected at the application layer as "not appropriate for 0-RTT data", which requires the application to know if the request was received over 0-RTT data.

-Ben
--------------A89820F635BCB5AE4A1C942C-- From nobody Tue Jun 13 11:07:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0277131A0B for ; Tue, 13 Jun 2017 11:07:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, URIBL_BLOCKED=0.001] 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 ab04cSl52BiD for ; Tue, 13 Jun 2017 11:07:38 -0700 (PDT) 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 19FB612954C for ; Tue, 13 Jun 2017 11:07:37 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id 63so55290271ywr.0 for ; Tue, 13 Jun 2017 11:07:37 -0700 (PDT) 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=0pah7hAmvti9RvbA0zR3U00TpDvw/GxIp9WAO4d4YR4=; b=GKKQhLUi60zU6yiycXOGqAhlggkVHIEEJprZRBsSQ2dcHu6BKim0tsbbEZwVNYrtMr iEiEX072mJZFdfooOk86fZF+LBUd2W8AoSibq3wjl8KvPHjOzEmhzkQeKvwpOwKnO+lA x23HfxSoF1p1WkodL0kkkPt9zxTyPIpRoEjMgNVE3hZyFOJoRPenihpIqNcZ3Xu+F18n CzoFNsFk2topTxWSL/YR8I0tnoz6EsLb+UGLhR/H9+KR0MrEc0ZW62Rq/0BiAzsAPYBs eCmhXXiX6JwSxl7ueyGIsPNA1WXyUArsvA+bojQpvU8+gOvfTi8JyiQrOsRUpRFxAnB7 hchg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0pah7hAmvti9RvbA0zR3U00TpDvw/GxIp9WAO4d4YR4=; b=llmIS+eCRvnZHsaSYLNDp3/AlKd9nY7KsQsk+Cb8cTd7HKtOyMszvbVG9xO5nBzPAu JxwpCSJD9Hm8GsrAzM3mgtc2HVg1iGM0d0NwfauE1EJx8C0fL/saNI7ogX/0szZYbDUz nRYU0Uj0BKYSdbigW4PolJ/WG6uLFnJDVSS5WNvG/Ttxuh1U0XRL55A5ADUyHeKKQeJX BHaTD1pSqlRZcwPsAw0LKqVVYkJNLqNimsU5wpQD5GQfK7DSWFaac3QDkl/lZBvH+VhH 34lqgUZ8/YaghrufawL8cgAEibPoEUp6tL4CZAB0jdtjNuuBwW0/a0B6UdQnYN4OTemq 6/3A== X-Gm-Message-State: AKS2vOyqO3its3BadhEh9t+hWFAILmUKUjgvdTvoEtNaLOfK0vyxqv+Q xvSotkLxuG8Tr+bX4MmZaAWKMMZQfsr1 X-Received: by 10.129.50.209 with SMTP id y200mr4670481ywy.241.1497377256403; Tue, 13 Jun 2017 11:07:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.93.70 with HTTP; Tue, 13 Jun 2017 11:07:35 -0700 (PDT) In-Reply-To: References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Tue, 13 Jun 2017 11:07:35 -0700 Message-ID: To: Benjamin Kaduk Cc: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114087207681680551db4f01" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 18:07:41 -0000 --001a114087207681680551db4f01 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk wrote: > I have been operating under the impression that at least some application > profiles for early data will require that certain application protocol > requests (e.g., something like HTTP POST) must be rejected at the > application layer as "not appropriate for 0-RTT data", which requires the > application to know if the request was received over 0-RTT data. > That's a really good point; you've changed my mind. It's obviously a good idea to return a 5XX to a POST over 0-RTT and that would need this. -- Colm --001a114087207681680551db4f01 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Tue, Jun 13, 2017 at 11:= 04 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
I have been operating under the impression that at least some application profiles for early data will require that certain application protocol requests (e.g., something like HTTP POST) must be rejected at the application layer as "not appropriate for 0-RTT data", which requires the application to know if the request was received over 0-RTT data.

That's a really good point; you've changed my mind. It&= #39;s obviously a good idea to return a 5XX to a POST over 0-RTT and that w= ould need this.=C2=A0

--
Colm
--001a114087207681680551db4f01-- From nobody Tue Jun 13 11:12:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E34241293FD for ; Tue, 13 Jun 2017 11:12:16 -0700 (PDT) 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=[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, URIBL_BLOCKED=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 yPHLB4DC1iQx for ; Tue, 13 Jun 2017 11:12:14 -0700 (PDT) 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 E9C1F1243F6 for ; Tue, 13 Jun 2017 11:12:13 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id e11so35109039oia.2 for ; Tue, 13 Jun 2017 11:12:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WV4AiRG4quV/u+vz3q88W+1WRbpI/1lAIc9j7Onxtsg=; b=fmRWhmf75IbZCWrYA6vylIfK9ZwoBbMBdzzDjvTgmEjKDo8CsEU2EAVdKs8X2bZ+eg 0zhXdpYHhmGVBk6KTIKtlg4PexOtgR05PfEW34hrPk8VKqqje3Kykv2QSMXsSh8iiIYD SY4OEPmoWKXIpy5gai0MNvcBqzY8VbTg1N3DdXVZ1j8yYq3zSkgcV1NYewYA6lfjduuk Wggqg8CtdTblXA+xkaRRN7ojpb2ciyG0uGBivAoyLv5sWLeHrhSDnw0PWyQSdRvdegUt q2b61h2JJC8hz5a5thro8fx4WtkVh7BN9pNt9sqBvRA4PoGZE1vuu4Y5g1o52+DALONM WgkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WV4AiRG4quV/u+vz3q88W+1WRbpI/1lAIc9j7Onxtsg=; b=qFAEtofVdJAOElWlCcVtpYDyKf/n123Kw6cuphf+/gykB2UUuOUhtQAauK+kE0jKxK gR5XJT+ljbcxaiQocDEmH8Xj+O3+iZyPEZMB9a0QAfhMmCZ/qIqb6uru5FwlYXoVT+pi mngtyb3PmOouVFPD2zVBdffJA/29tQyLFZlwLgoosnw2oJ0ysuKIxzoNSvg2+PZukoux fwW7r3Oq6W+omre/Xt0aKUN8H0uOLXz7fDzalIbS2DwO+NuxpjSyH8AcgDHxorW4OnlM ZDuWUa5wuCJvmMn34xkxKlfDgnRb9pQYGp9Xylc/FiY1wL+GQVheiKd3GbcovFCTX/HX cyXw== X-Gm-Message-State: AKS2vOyJeByg4fcquvbA6gDXKVsoZ3akB5BPmzAfN4Fu5qvR0IgW5vCC JoGfCRXdiAgFp6r+ouCPWIPZ6bTCjw== X-Received: by 10.202.87.213 with SMTP id l204mr891346oib.163.1497377533355; Tue, 13 Jun 2017 11:12:13 -0700 (PDT) MIME-Version: 1.0 References: <20170613075609.GA8983@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: <20170613075609.GA8983@LK-Perkele-V2.elisa-laajakaista.fi> From: Nick Sullivan Date: Tue, 13 Jun 2017 18:12:02 +0000 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113ad0a2f86c490551db5f44" Archived-At: Subject: Re: [TLS] Exported Authenticators proposed updates X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 18:12:17 -0000 --001a113ad0a2f86c490551db5f44 Content-Type: text/plain; charset="UTF-8" Thanks for the comments. I've updated the PRs appropriately. On Tue, Jun 13, 2017 at 12:56 AM Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 12:32:12AM +0000, Nick Sullivan wrote: > > All, > > > > I've collected a few changes that help clarify some ambiguities brought > up > > on the list and during implementation of the draft. These changes are > laid > > out as the following PRs in Github: > > > > Restrict the Certificate type to standard X.509 certificates. > > https://github.com/grittygrease/tls-exported-authenticator/pull/20 > > Supporting certificates that are not X.509 actually brings major > complications in protocol like this. The TLS library must > recognize those types in order to properly extract the key > needed to verify the CertificateVerify. The type extension can't > just be skipped. > > > Also, for related reasons, when implementing client certificates > in TLS library I am working on, I only implemented X.509, despite the > library supporting authentication based on keys, and RPK being > supported for server authentication. The reason for this was the > pretty nasty interaction of certificate types with client > certificates. > > > Relax requirement for the certificate_request_context to be unique, > clarify > > the benefits of doing so. > > https://github.com/grittygrease/tls-exported-authenticator/pull/18 > > Might also note unpredictability. And then note what happens if > uniqueness (replays of the same certificate) or unpredictability > (pregenerating responses) fails. Neither seems catastrophic (unlike, > say repeating a nonce in AEAD). > > After all, the certificate contexts in TLS 1.3 discuss > unpredictability. > Good comment. I added some text to reflect this. > > > Be more explicit about how signature schemes are chosen and supported. > > https://github.com/grittygrease/tls-exported-authenticator/pull/18 > > This seems to be only place where non-standard APIs are required from > the TLS library itself (I don't think most TLS APIs that do have > exporters and EMS indication have facility to obtain the list of > algorithms supported). > For this API, the server needs to know which signature algorithms the client supports and use that to make the correct choice of certificate. The signature schemes will have to be available already for servers to do dynamic certificate selection, so I don't see this as a big ask. > > And the client side is supposed to have a call for obtaining the > supported algorithms anyway. > > Why not always operate on TLS 1.3 semantics, regardless of transport > version? Main implications would be always using PSS with RSA and > not mixing ECDSA curves and hashes. > This would simplify the logic substantially. I don't see any problems with eliminating PKCS#1 1.5 altogether. I have updated the PR. > > > -Ilari > --001a113ad0a2f86c490551db5f44 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the comments. I've updated the PRs appropri= ately.

On Tue, Jun = 13, 2017 at 12:56 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
On Tue, Jun 13, 2017 at 12:32:12AM +0000, Nick Sullivan wrot= e:
> All,
>
> I've collected a few changes that help clarify some ambiguities br= ought up
> on the list and during implementation of the draft. These changes are = laid
> out as the following PRs in Github:
>
> Restrict the Certificate type to standard X.509 certificates.
> https://github.com/grittygrea= se/tls-exported-authenticator/pull/20

Supporting certificates that are not X.509 actually brings major
complications in protocol like this. The TLS library must
recognize those types in order to properly extract the key
needed to verify the CertificateVerify. The type extension can't
just be skipped.


Also, for related reasons, when implementing client certificates
in TLS library I am working on, I only implemented X.509, despite the
library supporting authentication based on keys, and RPK being
supported for server authentication. The reason for this was the
pretty nasty interaction of certificate types with client
certificates.=C2=A0

> Relax requirement for the certificate_request_context to be unique, cl= arify
> the benefits of doing so.
> https://github.com/grittygrea= se/tls-exported-authenticator/pull/18

Might also note unpredictability. And then note what happens if
uniqueness (replays of the same certificate) or unpredictability
(pregenerating responses) fails. Neither seems catastrophic (unlike,
say repeating a nonce in AEAD).

After all, the certificate contexts in TLS 1.3 discuss
unpredictability.

Good comment. I added= some text to reflect this.

> Be more explicit about how signature schemes are chosen and supported.=
> https://github.com/grittygrea= se/tls-exported-authenticator/pull/18

This seems to be only place where non-standard APIs are required from
the TLS library itself (I don't think most TLS APIs that do have
exporters and EMS indication have facility to obtain the list of
algorithms supported).=C2=A0
=C2=A0
For this= API, the server needs to know which signature algorithms the client suppor= ts and use that to make the correct choice of certificate. The signature sc= hemes will have to be available already for servers to do dynamic certifica= te selection, so I don't see this as a big ask.
=C2=A0

And the client side is supposed to have a call for obtaining the
supported algorithms anyway.

Why not always operate on TLS 1.3 semantics, regardless of transport
version? Main implications would be always using PSS with RSA and
not mixing ECDSA curves and hashes.

This would sim= plify the logic substantially. I don't see any problems with eliminatin= g PKCS#1 1.5 altogether. I have updated the PR.
=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">

-Ilari
--001a113ad0a2f86c490551db5f44-- From nobody Tue Jun 13 11:35:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F60B129488 for ; Tue, 13 Jun 2017 11:35:48 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 GSQdqQG8rbs5 for ; Tue, 13 Jun 2017 11:35:46 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id B79FB127843 for ; Tue, 13 Jun 2017 11:35:44 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 6C29239609; Tue, 13 Jun 2017 21:35:42 +0300 (EEST) 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 7CdX5rOBgOFq; Tue, 13 Jun 2017 21:35:41 +0300 (EEST) 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 6C4192313; Tue, 13 Jun 2017 21:35:41 +0300 (EEST) Date: Tue, 13 Jun 2017 21:35:36 +0300 From: Ilari Liusvaara To: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= Cc: Benjamin Kaduk , "tls@ietf.org" Message-ID: <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 18:35:48 -0000 On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote: > On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk wrote: > > > I have been operating under the impression that at least some application > > profiles for early data will require that certain application protocol > > requests (e.g., something like HTTP POST) must be rejected at the > > application layer as "not appropriate for 0-RTT data", which requires the > > application to know if the request was received over 0-RTT data. > > > > > That's a really good point; you've changed my mind. It's obviously a good > idea to return a 5XX to a POST over 0-RTT and that would need this. I think the proper code to send is 400. The request is client error, nor server error, so it is 4XX. And there does not seem to be suitable 4XX code, so it goes to catch-all client error code 400. For HTTP/2, refusing the stream (sending stream error 7 without sending server headers) is also a good choice, as this should trigger a retransmission of the offending request (POST requests failed by refusing the stream are retryable). -Ilari From nobody Tue Jun 13 11:47:49 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC09F129409 for ; Tue, 13 Jun 2017 11:47:47 -0700 (PDT) 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 QVpja3FluXtO for ; Tue, 13 Jun 2017 11:47:46 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 E3904128B44 for ; Tue, 13 Jun 2017 11:47:45 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DIlDlr008560; Tue, 13 Jun 2017 19:47:43 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=ugMM0dctHeQSro64oKofo13PEUWsDdGVsyVXthTFpzI=; b=eZpj1FrOa0j0HhOQ2RPWRGQD8L6d2Z0O7yeiQjc1gX7O5kbWeipViYw0qVpEa8xBICFd jhxyK0vjRveIm6L06A9LEqojdBZ5knGxJOEcdS9DVb+7DWtmbmEJOkscQJ76vPwu8tvn 0YaDEuUI5ZPh2MkqkGZKryTzG6qXNhmPo/27D+QbQ8show7wrcrOVXslWDwcUbSytbwo qdrCs4AITIj98t1N8RMC152qkR5OClMBJUCKGMYLp7Isc494oPTiarvTdioz4udGtas5 Hv9ORNmJE15faDtcd6qlwivcU9sfpBzj/g0WxwUq88v1nvmjPOnesEipIR5HC5RZJfMA qw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2b2ndv82h1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 19:47:43 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DIjqKu014547; Tue, 13 Jun 2017 14:47:42 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b0c3vqw1y-1; Tue, 13 Jun 2017 14:47:42 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 8B2C720061; Tue, 13 Jun 2017 12:47:41 -0600 (MDT) To: Ilari Liusvaara , =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= Cc: "tls@ietf.org" References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk Message-ID: <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> Date: Tue, 13 Jun 2017 13:47:41 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: multipart/alternative; boundary="------------0ED2886034D9F9C36607C235" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130320 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130321 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 18:47:48 -0000 This is a multi-part message in MIME format. --------------0ED2886034D9F9C36607C235 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/13/2017 01:35 PM, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote: >> On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk wrote: >> >>> I have been operating under the impression that at least some application >>> profiles for early data will require that certain application protocol >>> requests (e.g., something like HTTP POST) must be rejected at the >>> application layer as "not appropriate for 0-RTT data", which requires the >>> application to know if the request was received over 0-RTT data. >>> >> >> That's a really good point; you've changed my mind. It's obviously a good >> idea to return a 5XX to a POST over 0-RTT and that would need this. > I think the proper code to send is 400. The request is client error, > nor server error, so it is 4XX. And there does not seem to be suitable > 4XX code, so it goes to catch-all client error code 400. > > For HTTP/2, refusing the stream (sending stream error 7 without sending > server headers) is also a good choice, as this should trigger a > retransmission of the offending request (POST requests failed by > refusing the stream are retryable). > At least the http 0-RTT profile that I started writing was going to allocate a new 4XX error code for this purpose. I am under no pretense that my version of such a document will resemble anything that finally gets published, though. -Ben --------------0ED2886034D9F9C36607C235 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/13/2017 01:35 PM, Ilari Liusvaara wrote:
On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote:

On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:


I have been operating under the impression that at least some application
profiles for early data will require that certain application protocol
requests (e.g., something like HTTP POST) must be rejected at the
application layer as "not appropriate for 0-RTT data", which requires the
application to know if the request was received over 0-RTT data.



That's a really good point; you've changed my mind. It's obviously a good
idea to return a 5XX to a POST over 0-RTT and that would need this.

I think the proper code to send is 400. The request is client error,
nor server error, so it is 4XX. And there does not seem to be suitable
4XX code, so it goes to catch-all client error code 400.

For HTTP/2, refusing the stream (sending stream error 7 without sending
server headers)  is also a good choice, as this should trigger a
retransmission of the offending request (POST requests failed by
refusing the stream are retryable).

At least the http 0-RTT profile that I started writing was going to allocate a new 4XX error code for this purpose.  I am under no pretense that my version of such a document will resemble anything that finally gets published, though.

-Ben
--------------0ED2886034D9F9C36607C235-- From nobody Tue Jun 13 11:57:11 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CEAB8129486 for ; Tue, 13 Jun 2017 11:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 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, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=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 IS8qL0Pw3xKR for ; Tue, 13 Jun 2017 11:57:07 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0102.outbound.protection.outlook.com [104.47.32.102]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E339A129409 for ; Tue, 13 Jun 2017 11:57:06 -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=XS+75at/YpL14tGrR4/98Z6+0yrn0G7oexm0jZDPtpA=; b=erGyDDHJ7MLtKr8nvxUju2Tto/VrobvuhsT77QN8XhrFuQobdn6cwuiDwEsT/uu76iVIY21OWqM7DTZg/QYa4GwnToUYi+YD432Wue+j8+AjXuQtlwcONYgQGv28RwfshW31QcmBmi73QjMZrWl6HO/EqwkTm3uZ2JFlhl8MUcI= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0058.namprd21.prod.outlook.com (10.161.140.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.3; Tue, 13 Jun 2017 18:57:05 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2d6d:96d3:f164:d70f]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2d6d:96d3:f164:d70f%15]) with mapi id 15.01.1199.000; Tue, 13 Jun 2017 18:57:05 +0000 From: Andrei Popov To: Benjamin Kaduk , Ilari Liusvaara , =?utf-8?B?Q29sbSBNYWNDw6FydGhhaWdo?= CC: "tls@ietf.org" Thread-Topic: [TLS] Separate APIs for 0-RTT Thread-Index: AQHS5B82VxUJW2RS/kmCucGOID4L7aIit00AgAABTICAAD1wkIAABhGAgAAS9ICAAAKWgIAABRGAgAAA6oCAAAfUAIAAA2CAgAACI1A= Date: Tue, 13 Jun 2017 18:57:05 +0000 Message-ID: References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> In-Reply-To: <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> 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:b::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0058; 7:6nPrgEzYfpnAQYsoipqLkgxy49lr+hhPNegiDta02a+8/vtJptUF0PjyyM9qd9UBH767n1C5sdp39jFFo5nkHLsPJq0orykKiw/iUHpQwsdtjEg2Act0Qe4Fnfhveto+RmMP0JlXW3U0TOqwjltOCZnZTeh1exa/xwpeyn7lwYKf5nDCHmu9YLE7uD8FdM/4lAIko0PAbKMIW9TOMqnzAA3p5R6969glSG9OseTou3G0jK2bfiu0VU6NtoI1yNCVgcVd8gnBL0zeCaTyCYy/GzvS0u3tiInkv5i/mQixwuv/lH6ddQ0JN5rdRhcdWr7YpmZTvdswndndd1BerNjI1DCMEj3eE2qG2yim93WwKAI0cIQAlKFEuf5zLvKod57GERnMVs3Kg6VG1pdVaZQNUa5PsuxosyWu5artYr2D7pXRCYraZhFPCNuColJnJ+/ChPTgPugRkVSj3qigHS85NRvQqqUHqgct96Bfk83pkHPIO5ivsit7CzOAcAeLDkHLCOZBQDrOpS9yBOHTZUZEQYjf29kvk56afLSk6ohBstMf3oUJqryWp6scAD8/RYCm11WszQVCXtM44+rRMbx2oQcK29ykJzwaabP2v9LPiZQwGoCfGPH07sFM/nNPeAXM07GgvqGtuqVvYyaU2asJfRu/ju+GDjhOpDHemYjL1CD9z9CLKd68Gw+l589Sv8TPYbCydyhd7XXc5b1ES19TRrFzlwsj0jwbmo8ThQPybNP1hK1wgqqx5sW7E4Ns8mwG4kVLs68/MAYd9o4BPpF6wy42uutfLY1Mb3Ql73IhxYxfM4WEOPH8CqF5K/wxPjiv x-ms-office365-filtering-correlation-id: 279e53db-1e35-4799-a975-08d4b28dfbec x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR21MB0058; x-ms-traffictypediagnostic: DM2PR21MB0058: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(93006095)(93001095)(10201501046)(100000703101)(100105400095)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123560025)(20161123562025)(20161123555025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0058; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0058; x-forefront-prvs: 0337AFFE9A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39450400003)(39840400002)(39850400002)(39400400002)(39410400002)(24454002)(377454003)(199003)(189002)(6116002)(7696004)(790700001)(14454004)(102836003)(7736002)(53546009)(2900100001)(81156014)(97736004)(8676002)(8936002)(81166006)(229853002)(25786009)(5660300001)(2906002)(4326008)(72206003)(74316002)(3280700002)(2950100002)(5250100002)(3660700001)(106356001)(6506006)(6436002)(9686003)(54896002)(6306002)(236005)(55016002)(99286003)(68736007)(10290500003)(478600001)(189998001)(53936002)(105586002)(38730400002)(6246003)(101416001)(54356999)(76176999)(86612001)(33656002)(8990500004)(5005710100001)(10090500001)(50986999)(86362001)(93886004); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0058; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX: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_DM2PR21MB0091B8DC8780B4FA67464F0A8CC20DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2017 18:57:05.1045 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0058 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 18:57:10 -0000 --_000_DM2PR21MB0091B8DC8780B4FA67464F0A8CC20DM2PR21MB0091namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVnYXJkaW5nIFJGQyBsYW5ndWFnZSwgSSB0aGluayB3ZSBjb3VsZCBiZSBtb3JlIHNwZWNpZmlj Og0KDQoNCg0KMS4gQSBUTFMgaW1wbGVtZW50YXRpb24gU0hPVUxEL01VU1Qgb25seSBzZW5kIDAt UlRUIGFwcGxpY2F0aW9uIGRhdGEgaWYgdGhlIGFwcGxpY2F0aW9uIGhhcyBleHBsaWNpdGx5IG9w dGVkIGluOw0KDQoyLiBBIFRMUyBpbXBsZW1lbnRhdGlvbiBTSE9VTEQvTVVTVCBvbmx5IGFjY2Vw dCAwLVJUVCBhcHBsaWNhdGlvbiBkYXRhIGlmIHRoZSBhcHBsaWNhdGlvbiBoYXMgZXhwbGljaXRs eSBvcHRlZCBpbjsNCg0KMy4gV2hlbiBkZWxpdmVyaW5nIDAtUlRUIGFwcGxpY2F0aW9uIGRhdGEg dG8gdGhlIGFwcGxpY2F0aW9uLCBhIFRMUyBpbXBsZW1lbnRhdGlvbiBTSE9VTEQvTVVTVCBwcm92 aWRlIGEgd2F5IGZvciB0aGUgYXBwbGljYXRpb24gdG8gZGlzdGluZ3Vpc2ggaXQgZnJvbSB0aGUg cmVzdCBvZiB0aGUgYXBwbGljYXRpb24gZGF0YS4NCg0KDQoNCk9yIHNvbWUgYmV0dGVyIHBocmFz aW5nIHRoYXQgb3VyIGNhcGFibGUgZWRpdG9yIGNhbiBjcmFmdPCfmIouDQoNCg0KDQpDaGVlcnMs DQoNCg0KDQpBbmRyZWkNCg0KRnJvbTogVExTIFttYWlsdG86dGxzLWJvdW5jZXNAaWV0Zi5vcmdd IE9uIEJlaGFsZiBPZiBCZW5qYW1pbiBLYWR1aw0KU2VudDogVHVlc2RheSwgSnVuZSAxMywgMjAx NyAxMTo0OCBBTQ0KVG86IElsYXJpIExpdXN2YWFyYSA8aWxhcmlsaXVzdmFhcmFAd2VsaG8uY29t PjsgQ29sbSBNYWNDw6FydGhhaWdoIDxjb2xtQGFsbGNvc3RzLm5ldD4NCkNjOiB0bHNAaWV0Zi5v cmcNClN1YmplY3Q6IFJlOiBbVExTXSBTZXBhcmF0ZSBBUElzIGZvciAwLVJUVA0KDQpPbiAwNi8x My8yMDE3IDAxOjM1IFBNLCBJbGFyaSBMaXVzdmFhcmEgd3JvdGU6DQoNCg0KT24gVHVlLCBKdW4g MTMsIDIwMTcgYXQgMTE6MDc6MzVBTSAtMDcwMCwgQ29sbSBNYWNDw6FydGhhaWdoIHdyb3RlOg0K DQpPbiBUdWUsIEp1biAxMywgMjAxNyBhdCAxMTowNCBBTSwgQmVuamFtaW4gS2FkdWsgPGJrYWR1 a0Bha2FtYWkuY29tPjxtYWlsdG86YmthZHVrQGFrYW1haS5jb20+IHdyb3RlOg0KDQoNCg0KSSBo YXZlIGJlZW4gb3BlcmF0aW5nIHVuZGVyIHRoZSBpbXByZXNzaW9uIHRoYXQgYXQgbGVhc3Qgc29t ZSBhcHBsaWNhdGlvbg0KDQpwcm9maWxlcyBmb3IgZWFybHkgZGF0YSB3aWxsIHJlcXVpcmUgdGhh dCBjZXJ0YWluIGFwcGxpY2F0aW9uIHByb3RvY29sDQoNCnJlcXVlc3RzIChlLmcuLCBzb21ldGhp bmcgbGlrZSBIVFRQIFBPU1QpIG11c3QgYmUgcmVqZWN0ZWQgYXQgdGhlDQoNCmFwcGxpY2F0aW9u IGxheWVyIGFzICJub3QgYXBwcm9wcmlhdGUgZm9yIDAtUlRUIGRhdGEiLCB3aGljaCByZXF1aXJl cyB0aGUNCg0KYXBwbGljYXRpb24gdG8ga25vdyBpZiB0aGUgcmVxdWVzdCB3YXMgcmVjZWl2ZWQg b3ZlciAwLVJUVCBkYXRhLg0KDQoNCg0KDQoNCg0KDQpUaGF0J3MgYSByZWFsbHkgZ29vZCBwb2lu dDsgeW91J3ZlIGNoYW5nZWQgbXkgbWluZC4gSXQncyBvYnZpb3VzbHkgYSBnb29kDQoNCmlkZWEg dG8gcmV0dXJuIGEgNVhYIHRvIGEgUE9TVCBvdmVyIDAtUlRUIGFuZCB0aGF0IHdvdWxkIG5lZWQg dGhpcy4NCg0KDQoNCkkgdGhpbmsgdGhlIHByb3BlciBjb2RlIHRvIHNlbmQgaXMgNDAwLiBUaGUg cmVxdWVzdCBpcyBjbGllbnQgZXJyb3IsDQoNCm5vciBzZXJ2ZXIgZXJyb3IsIHNvIGl0IGlzIDRY WC4gQW5kIHRoZXJlIGRvZXMgbm90IHNlZW0gdG8gYmUgc3VpdGFibGUNCg0KNFhYIGNvZGUsIHNv IGl0IGdvZXMgdG8gY2F0Y2gtYWxsIGNsaWVudCBlcnJvciBjb2RlIDQwMC4NCg0KDQoNCkZvciBI VFRQLzIsIHJlZnVzaW5nIHRoZSBzdHJlYW0gKHNlbmRpbmcgc3RyZWFtIGVycm9yIDcgd2l0aG91 dCBzZW5kaW5nDQoNCnNlcnZlciBoZWFkZXJzKSAgaXMgYWxzbyBhIGdvb2QgY2hvaWNlLCBhcyB0 aGlzIHNob3VsZCB0cmlnZ2VyIGENCg0KcmV0cmFuc21pc3Npb24gb2YgdGhlIG9mZmVuZGluZyBy ZXF1ZXN0IChQT1NUIHJlcXVlc3RzIGZhaWxlZCBieQ0KDQpyZWZ1c2luZyB0aGUgc3RyZWFtIGFy ZSByZXRyeWFibGUpLg0KDQoNCg0KQXQgbGVhc3QgdGhlIGh0dHAgMC1SVFQgcHJvZmlsZSB0aGF0 IEkgc3RhcnRlZCB3cml0aW5nIHdhcyBnb2luZyB0byBhbGxvY2F0ZSBhIG5ldyA0WFggZXJyb3Ig Y29kZSBmb3IgdGhpcyBwdXJwb3NlLiAgSSBhbSB1bmRlciBubyBwcmV0ZW5zZSB0aGF0IG15IHZl cnNpb24gb2Ygc3VjaCBhIGRvY3VtZW50IHdpbGwgcmVzZW1ibGUgYW55dGhpbmcgdGhhdCBmaW5h bGx5IGdldHMgcHVibGlzaGVkLCB0aG91Z2guDQoNCi1CZW4NCg== --_000_DM2PR21MB0091B8DC8780B4FA67464F0A8CC20DM2PR21MB0091namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDb25zb2xhczsNCglwYW5vc2UtMToyIDEx IDYgOSAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmOw0KCWNvbG9yOmJsYWNrO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7 bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENo YXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcHJlDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hh ciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCWNvbG9yOmJsYWNrO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6 YmxhY2s7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRN TCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJY29s b3I6YmxhY2s7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwt cmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBU ZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2 OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAg djpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZd LS0+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJs dWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNz PSJNc29QbGFpblRleHQiPlJlZ2FyZGluZyBSRkMgbGFuZ3VhZ2UsIEkgdGhpbmsgd2UgY291bGQg YmUgbW9yZSBzcGVjaWZpYzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+MS4gQSBUTFMg aW1wbGVtZW50YXRpb24gU0hPVUxEL01VU1Qgb25seSBzZW5kIDAtUlRUIGFwcGxpY2F0aW9uIGRh dGEgaWYgdGhlIGFwcGxpY2F0aW9uIGhhcyBleHBsaWNpdGx5IG9wdGVkIGluOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+Mi4gQSBUTFMgaW1wbGVtZW50YXRpb24gU0hP VUxEL01VU1Qgb25seSBhY2NlcHQgMC1SVFQgYXBwbGljYXRpb24gZGF0YSBpZiB0aGUgYXBwbGlj YXRpb24gaGFzIGV4cGxpY2l0bHkgb3B0ZWQgaW47PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4zLiBXaGVuIGRlbGl2ZXJpbmcgMC1SVFQgYXBwbGljYXRpb24gZGF0YSB0 byB0aGUgYXBwbGljYXRpb24sIGEgVExTIGltcGxlbWVudGF0aW9uIFNIT1VMRC9NVVNUIHByb3Zp ZGUgYSB3YXkgZm9yIHRoZSBhcHBsaWNhdGlvbiB0byBkaXN0aW5ndWlzaCBpdCBmcm9tIHRoZSBy ZXN0IG9mIHRoZSBhcHBsaWNhdGlvbiBkYXRhLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0 Ij5PciBzb21lIGJldHRlciBwaHJhc2luZyB0aGF0IG91ciBjYXBhYmxlIGVkaXRvciBjYW4gY3Jh ZnQ8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkgRW1vamkmcXVvdDssc2Fu cy1zZXJpZiI+JiMxMjg1MjI7PC9zcGFuPi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Q bGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+ Q2hlZXJzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5BbmRyZWk8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAw aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOndpbmRvd3Rl eHQiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dCI+IFRMUyBb bWFpbHRvOnRscy1ib3VuY2VzQGlldGYub3JnXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj5CZW5qYW1p biBLYWR1azxicj4NCjxiPlNlbnQ6PC9iPiBUdWVzZGF5LCBKdW5lIDEzLCAyMDE3IDExOjQ4IEFN PGJyPg0KPGI+VG86PC9iPiBJbGFyaSBMaXVzdmFhcmEgJmx0O2lsYXJpbGl1c3ZhYXJhQHdlbGhv LmNvbSZndDs7IENvbG0gTWFjQ8OhcnRoYWlnaCAmbHQ7Y29sbUBhbGxjb3N0cy5uZXQmZ3Q7PGJy Pg0KPGI+Q2M6PC9iPiB0bHNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtUTFNd IFNlcGFyYXRlIEFQSXMgZm9yIDAtUlRUPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+T24gMDYvMTMvMjAxNyAwMTozNSBQTSwgSWxhcmkgTGl1c3ZhYXJhIHdy b3RlOjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cHJlPk9uIFR1ZSwgSnVuIDEzLCAy MDE3IGF0IDExOjA3OjM1QU0gLTA3MDAsIENvbG0gTWFjQ8OhcnRoYWlnaCB3cm90ZTo8bzpwPjwv bzpwPjwvcHJlPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCI+DQo8cHJlPk9uIFR1ZSwgSnVuIDEzLCAyMDE3IGF0IDExOjA0IEFNLCBCZW5q YW1pbiBLYWR1ayA8YSBocmVmPSJtYWlsdG86YmthZHVrQGFrYW1haS5jb20iPiZsdDtia2FkdWtA YWthbWFpLmNvbSZndDs8L2E+IHdyb3RlOjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5i c3A7PC9vOnA+PC9wcmU+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJn aW4tYm90dG9tOjUuMHB0Ij4NCjxwcmU+SSBoYXZlIGJlZW4gb3BlcmF0aW5nIHVuZGVyIHRoZSBp bXByZXNzaW9uIHRoYXQgYXQgbGVhc3Qgc29tZSBhcHBsaWNhdGlvbjxvOnA+PC9vOnA+PC9wcmU+ DQo8cHJlPnByb2ZpbGVzIGZvciBlYXJseSBkYXRhIHdpbGwgcmVxdWlyZSB0aGF0IGNlcnRhaW4g YXBwbGljYXRpb24gcHJvdG9jb2w8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZXF1ZXN0cyAoZS5n Liwgc29tZXRoaW5nIGxpa2UgSFRUUCBQT1NUKSBtdXN0IGJlIHJlamVjdGVkIGF0IHRoZTxvOnA+ PC9vOnA+PC9wcmU+DQo8cHJlPmFwcGxpY2F0aW9uIGxheWVyIGFzICZxdW90O25vdCBhcHByb3By aWF0ZSBmb3IgMC1SVFQgZGF0YSZxdW90Oywgd2hpY2ggcmVxdWlyZXMgdGhlPG86cD48L286cD48 L3ByZT4NCjxwcmU+YXBwbGljYXRpb24gdG8ga25vdyBpZiB0aGUgcmVxdWVzdCB3YXMgcmVjZWl2 ZWQgb3ZlciAwLVJUVCBkYXRhLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8 cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPlRoYXQncyBhIHJlYWxseSBnb29kIHBv aW50OyB5b3UndmUgY2hhbmdlZCBteSBtaW5kLiBJdCdzIG9idmlvdXNseSBhIGdvb2Q8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5pZGVhIHRvIHJldHVybiBhIDVYWCB0byBhIFBPU1Qgb3ZlciAwLVJU VCBhbmQgdGhhdCB3b3VsZCBuZWVkIHRoaXMuPG86cD48L286cD48L3ByZT4NCjwvYmxvY2txdW90 ZT4NCjxwcmU+PG86cD4mbmJzcDs8L286cD48L3ByZT4NCjxwcmU+SSB0aGluayB0aGUgcHJvcGVy IGNvZGUgdG8gc2VuZCBpcyA0MDAuIFRoZSByZXF1ZXN0IGlzIGNsaWVudCBlcnJvciw8bzpwPjwv bzpwPjwvcHJlPg0KPHByZT5ub3Igc2VydmVyIGVycm9yLCBzbyBpdCBpcyA0WFguIEFuZCB0aGVy ZSBkb2VzIG5vdCBzZWVtIHRvIGJlIHN1aXRhYmxlPG86cD48L286cD48L3ByZT4NCjxwcmU+NFhY IGNvZGUsIHNvIGl0IGdvZXMgdG8gY2F0Y2gtYWxsIGNsaWVudCBlcnJvciBjb2RlIDQwMC48bzpw PjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5Gb3IgSFRU UC8yLCByZWZ1c2luZyB0aGUgc3RyZWFtIChzZW5kaW5nIHN0cmVhbSBlcnJvciA3IHdpdGhvdXQg c2VuZGluZzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPnNlcnZlciBoZWFkZXJzKSZuYnNwOyBpcyBh bHNvIGEgZ29vZCBjaG9pY2UsIGFzIHRoaXMgc2hvdWxkIHRyaWdnZXIgYTxvOnA+PC9vOnA+PC9w cmU+DQo8cHJlPnJldHJhbnNtaXNzaW9uIG9mIHRoZSBvZmZlbmRpbmcgcmVxdWVzdCAoUE9TVCBy ZXF1ZXN0cyBmYWlsZWQgYnk8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5yZWZ1c2luZyB0aGUgc3Ry ZWFtIGFyZSByZXRyeWFibGUpLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9v OnA+PC9wcmU+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQpBdCBs ZWFzdCB0aGUgaHR0cCAwLVJUVCBwcm9maWxlIHRoYXQgSSBzdGFydGVkIHdyaXRpbmcgd2FzIGdv aW5nIHRvIGFsbG9jYXRlIGEgbmV3IDRYWCBlcnJvciBjb2RlIGZvciB0aGlzIHB1cnBvc2UuJm5i c3A7IEkgYW0gdW5kZXIgbm8gcHJldGVuc2UgdGhhdCBteSB2ZXJzaW9uIG9mIHN1Y2ggYSBkb2N1 bWVudCB3aWxsIHJlc2VtYmxlIGFueXRoaW5nIHRoYXQgZmluYWxseSBnZXRzIHB1Ymxpc2hlZCwg dGhvdWdoLjxicj4NCjxicj4NCi1CZW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0K PC9odG1sPg0K --_000_DM2PR21MB0091B8DC8780B4FA67464F0A8CC20DM2PR21MB0091namp_-- From nobody Tue Jun 13 12:03:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E8312944C for ; Tue, 13 Jun 2017 12:03:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 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, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 oP_38SZGlKO2 for ; Tue, 13 Jun 2017 12:03:27 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 10A32129488 for ; Tue, 13 Jun 2017 12:03:27 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5DIvqUV017113; Tue, 13 Jun 2017 20:03:24 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=c1hJUTkl4T25qsR9cmZkyKCMW70Vnk8j5tbeiGHBaLk=; b=T+XUG3BuJ3423w7jxSHMIc73d/eL0lP9Xa+Hh3hiFBKAhStjGGtQcl0rG/lftJV06IuJ H+fnbgcv7RCaAS/zNnFuIUf3jIjHDMWynItueS7FmmW3p8XLkIeWYnp0hlGfsIl/s/L3 rjG9YJs/EIWSjuU+RqLWb38bX4Me6sh31DxHeeGALbtPtQa34taqxR8PK9niAeF2AfNm lyNH/pO1CFuaquHtsI8+nGygjVEmMXwiYMpEboBRcXjsdIdrazaT0oLMT06C0pKwyqbF 17rUAo+JcQASTHPpeZINnhX2+u/JFsPQhrTciDALeXVGV0tipgRHmnppaAzM+cOko0wc 8g== Received: from prod-mail-ppoint2 (a184-51-33-19.deploy.static.akamaitechnologies.com [184.51.33.19] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b2ndv84hy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 13 Jun 2017 20:03:24 +0100 Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5DIu09B025469; Tue, 13 Jun 2017 15:03:23 -0400 Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2b0c3ub6ym-1; Tue, 13 Jun 2017 15:03:23 -0400 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 037631FC88; Tue, 13 Jun 2017 19:03:22 +0000 (GMT) To: Andrei Popov , Ilari Liusvaara , =?UTF-8?Q?Colm_MacC=c3=a1rthaigh?= Cc: "tls@ietf.org" References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> From: Benjamin Kaduk Message-ID: Date: Tue, 13 Jun 2017 14:03:22 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D89C7085199A50C01003E102" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130324 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706130324 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 19:03:30 -0000 This is a multi-part message in MIME format. --------------D89C7085199A50C01003E102 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit +1 (with my vote for MUST). -Ben On 06/13/2017 01:57 PM, Andrei Popov wrote: > > Regarding RFC language, I think we could be more specific: > > > > 1. A TLS implementation SHOULD/MUST only send 0-RTT application data > if the application has explicitly opted in; > > 2. A TLS implementation SHOULD/MUST only accept 0-RTT application data > if the application has explicitly opted in; > > 3. When delivering 0-RTT application data to the application, a TLS > implementation SHOULD/MUST provide a way for the application to > distinguish it from the rest of the application data. > > > > Or some better phrasing that our capable editor can craft😊. > > > > Cheers, > > > > Andrei > > > > *From:*TLS [mailto:tls-bounces@ietf.org] *On Behalf Of *Benjamin Kaduk > *Sent:* Tuesday, June 13, 2017 11:48 AM > *To:* Ilari Liusvaara ; Colm MacCárthaigh > > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Separate APIs for 0-RTT > > > > On 06/13/2017 01:35 PM, Ilari Liusvaara wrote: > > On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote: > > On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk wrote: > > > > I have been operating under the impression that at least some application > > profiles for early data will require that certain application protocol > > requests (e.g., something like HTTP POST) must be rejected at the > > application layer as "not appropriate for 0-RTT data", which requires the > > application to know if the request was received over 0-RTT data. > > > > > > > > That's a really good point; you've changed my mind. It's obviously a good > > idea to return a 5XX to a POST over 0-RTT and that would need this. > > > > I think the proper code to send is 400. The request is client error, > > nor server error, so it is 4XX. And there does not seem to be suitable > > 4XX code, so it goes to catch-all client error code 400. > > > > For HTTP/2, refusing the stream (sending stream error 7 without sending > > server headers) is also a good choice, as this should trigger a > > retransmission of the offending request (POST requests failed by > > refusing the stream are retryable). > > > > > At least the http 0-RTT profile that I started writing was going to > allocate a new 4XX error code for this purpose. I am under no > pretense that my version of such a document will resemble anything > that finally gets published, though. > > -Ben > --------------D89C7085199A50C01003E102 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit +1 (with my vote for MUST).

-Ben

On 06/13/2017 01:57 PM, Andrei Popov wrote:

Regarding RFC language, I think we could be more specific:

 

1. A TLS implementation SHOULD/MUST only send 0-RTT application data if the application has explicitly opted in;

2. A TLS implementation SHOULD/MUST only accept 0-RTT application data if the application has explicitly opted in;

3. When delivering 0-RTT application data to the application, a TLS implementation SHOULD/MUST provide a way for the application to distinguish it from the rest of the application data.

 

Or some better phrasing that our capable editor can craft😊.

 

Cheers,

 

Andrei

 

From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Benjamin Kaduk
Sent: Tuesday, June 13, 2017 11:48 AM
To: Ilari Liusvaara <ilariliusvaara@welho.com>; Colm MacCárthaigh <colm@allcosts.net>
Cc: tls@ietf.org
Subject: Re: [TLS] Separate APIs for 0-RTT

 

On 06/13/2017 01:35 PM, Ilari Liusvaara wrote:

On Tue, Jun 13, 2017 at 11:07:35AM -0700, Colm MacCárthaigh wrote:
On Tue, Jun 13, 2017 at 11:04 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
 
I have been operating under the impression that at least some application
profiles for early data will require that certain application protocol
requests (e.g., something like HTTP POST) must be rejected at the
application layer as "not appropriate for 0-RTT data", which requires the
application to know if the request was received over 0-RTT data.
 
 
 
That's a really good point; you've changed my mind. It's obviously a good
idea to return a 5XX to a POST over 0-RTT and that would need this.
 
I think the proper code to send is 400. The request is client error,
nor server error, so it is 4XX. And there does not seem to be suitable
4XX code, so it goes to catch-all client error code 400.
 
For HTTP/2, refusing the stream (sending stream error 7 without sending
server headers)  is also a good choice, as this should trigger a
retransmission of the offending request (POST requests failed by
refusing the stream are retryable).
 


At least the http 0-RTT profile that I started writing was going to allocate a new 4XX error code for this purpose.  I am under no pretense that my version of such a document will resemble anything that finally gets published, though.

-Ben


--------------D89C7085199A50C01003E102-- From nobody Tue Jun 13 12:06:31 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D085129488 for ; Tue, 13 Jun 2017 12:06:30 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 j1hUoEGtPjgy for ; Tue, 13 Jun 2017 12:06:28 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 8DC1A1270A0 for ; Tue, 13 Jun 2017 12:06:28 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id e142so48053010ywa.1 for ; Tue, 13 Jun 2017 12:06:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UQeGxfpZiUsUNHxavd/hd36TmHwCMoVCVsnNZ9lDJww=; b=rnxnMazseW3xf3+wWLD7HHes01d5kqh+6Pz8JP8tAzEw2WhBL796j8E+AN3nUIHCNj +iAmMWggMYygupzvGVcPfhiiyzT/TDSBRY2oNyODcS8dt/ByEGBFxdXkgKIft/zTSRFh f49mGOFnvP20T6sAvZPcLZLQmgi3K6HvZWacQMaXhRFhwvpGmr5kwP6Y5pGsJV7FdPd8 KwBL4qOS01c1EcmlLTe9epqANplX4DuLanj9FsGuHsRQ09ypvKHhQJD34AZMO41yu6U8 J/iO3jx1JOYYJmePQk2v8rUXlmUZ5UPAkZrHjSg6bOJnzjvpDHgBpWISM8pKhqYI2Ukn rDeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UQeGxfpZiUsUNHxavd/hd36TmHwCMoVCVsnNZ9lDJww=; b=f6ST9fGhqbMs7VFkg0BW0ZY6cjSRp9EslZgZfz7PU+/tnJ2+QLCUVH3R3BRNCZHjGB BjVjP+WEkZ36oz/uqGy8KjvzTvjJHGCoTpafCQQXuK46dY24oTpUPRWws/5p+4DJ4Jxn qyoITS1G6Gzd17Nm8JoMaXCnAt8pdmpSblx6ynhmXcHIttOvomXU0TZsHosm7Q8VAeCn JRCOZiIuRM9JCduAUhMLOHYRqPvdjnaOqtNS63U089Q8lUGovUzQXHRRXfAF+1Nf3NT6 M31qQ+gtYJa8vvObdOw2pPdRcAE3EL2tdk1rY20NY+UZLrVi2DCqBj6s+fU4qBGlyt51 Xawg== X-Gm-Message-State: AKS2vOx9Nsek8u8SEPHKyaJa28FudeJDtDRwqMhqJ6pYsF9UQ1immLMY pFYPgjQm3mDrCGTORVw7eeatyL0MkR+n X-Received: by 10.13.240.198 with SMTP id z189mr4307316ywe.239.1497380787510; Tue, 13 Jun 2017 12:06:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.222.67 with HTTP; Tue, 13 Jun 2017 12:06:26 -0700 (PDT) In-Reply-To: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> From: Bill Cox Date: Tue, 13 Jun 2017 12:06:26 -0700 Message-ID: To: Ilari Liusvaara Cc: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c034d1cef84a10551dc2134" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 19:06:30 -0000 --94eb2c034d1cef84a10551dc2134 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 4:32 AM, Ilari Liusvaara wrote: > Also: > > - Note that 0-RTT exporters are not safe for authentication unless > the server does global anti-replay on 0-RTT. I do not think this is the case. Nick Harper has proposed an RFC for token binding over 0-RTT: https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-02 In the same way servers can ensure tickets are single-use (by binding them to a server/metro/orbit and having local ticket caches), we can ensure that each retransmission carries a unique auth signature. I would state the situation like this: - Note that 0-RTT exporters are not safe for authentication on servers that do not enforce single-use tickets, or for clients that do not recompute authentication signatures on retransmission of early data. Even this is only partially true. Anti-replay can be built above the TLS layer. I'm considering doing token-binding replay defense in the authentication backend, to help ensure the token-binding guarantee: that auth tokens taken from one device cannot be used from another device without continued access to the first device's signing oracle. Unfortunately, 0-RTT master resumption secrets are a new kind of auth bearer token, and the token binding spec does not cover them. Bill --94eb2c034d1cef84a10551dc2134 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 13, 2017 at 4:32 AM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
Also:

- Note that 0-RTT exporters are not safe for authentication unless
=C2=A0 the server does global anti-replay on 0-RTT.

I do not think this is the case.=C2=A0 Nick Harper has proposed an= RFC for token binding over 0-RTT:

=C2=A0 =C2=A0 <= a href=3D"https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-02"= >https://tools.ietf.org/html/draft-nharper-0-rtt-token-binding-02

In the same way servers can ensure tickets are sing= le-use (by binding them to a server/metro/orbit and having local ticket cac= hes), we can ensure that each retransmission carries a unique auth signatur= e.=C2=A0 I would state the situation like this:

= =C2=A0 - Note that 0-RTT exporters are not safe for authentication on serve= rs that do not enforce single-use tickets, or for clients that do not recom= pute authentication signatures on retransmission of early data.
<= br>
Even this is only partially true.=C2=A0 Anti-replay can be bu= ilt above the TLS layer.=C2=A0 I'm considering doing token-binding repl= ay defense in the authentication backend, to help ensure the token-binding = guarantee: that auth tokens taken from one device cannot be used from anoth= er device without continued access to the first device's signing oracle= .=C2=A0 Unfortunately, 0-RTT master resumption secrets are a new kind of au= th bearer token, and the token binding spec does not cover them.
=
Bill
--94eb2c034d1cef84a10551dc2134-- From nobody Tue Jun 13 13:24:17 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EAB129AB5 for ; Tue, 13 Jun 2017 13:24:15 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 YRiFmAlY39_f for ; Tue, 13 Jun 2017 13:24:14 -0700 (PDT) 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 D66C8129A92 for ; Tue, 13 Jun 2017 13:24:13 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id u12so188853184qth.0 for ; Tue, 13 Jun 2017 13:24:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/xKcd3kHldOU/lTTeLM48PnUKc9SLsKNTZ6zF+bU5cU=; b=hNP9EnCRfz3HDIBTvk1knCd+n+3m/0Gp9woohMc5r6HRX4SbiaY9Mg1KIeJ1KsHBU8 ZJvbs7z1EsgJaq2qnyKAaQQSUNzrqZVWUz2homoOJ6FQhstznzVFeBJ9OCDia6ZeX+o5 H1dt6ELB48tKcUlmsIvGo5WdTjI8JdhTenXMoIkRudM6sWj2dPyeJb1o/R1jW97pfnM7 nzHUVyCGlRCVoFJE5usf773VuTi0Ra4kfbAwFZk7GkIxB/XFYfuaJ49CRcwjuS27tsOU nQyMcwdreFyzpt6By5suMETm/CyDXECyNuvQ6iayFMnR7GAJgzX6CnT3wKw3rkCKiryR ERFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/xKcd3kHldOU/lTTeLM48PnUKc9SLsKNTZ6zF+bU5cU=; b=pcMLySVI1VwhtG/hTct2e348Ur4mBr/SycKC64djyunndgn33+hZ3qV8/NjgafOmF6 jNGl+Sftm/AcsZ/EPnh8I8shwfnArSMh0y5TZnmiKF7A4Fky3VGGpzBm5uSI56caIoZN r9F8j7DV8pa4PeH/ACxZTWTfy2SOZw6aBbxE+L5k2GwwTjPYqwMkT7ndu7s12ZSBkwjQ TbTBJ1Ooe7fFObewkjEvGpAu8G1sc4J0WKCG48z8H0q2Mne9dg8iovgkhOdA/LIEEcgj D84Hmv5cYiCt6/7j30jVcZzzS4B8Hl+KBXRvGwB4RiWlrv/hQSIR+o7dEzGFfv3gVWL9 h3PQ== X-Gm-Message-State: AKS2vOzMk/nnAZN95JhA16Hh7MDu7mqjum0ALV3wJMzCXwYMvMFQPf+r AWfAI0amsozqlqKj4cpPzE+sTwFHzz9DHak= X-Received: by 10.55.77.209 with SMTP id a200mr2443086qkb.84.1497385452692; Tue, 13 Jun 2017 13:24:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.55.46.65 with HTTP; Tue, 13 Jun 2017 13:24:12 -0700 (PDT) In-Reply-To: References: From: Victor Vasiliev Date: Tue, 13 Jun 2017 16:24:12 -0400 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114a7e8c007ae70551dd388b" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 20:24:16 -0000 --001a114a7e8c007ae70551dd388b Content-Type: text/plain; charset="UTF-8" On Sun, Jun 11, 2017 at 11:18 AM, Eric Rescorla wrote: > Hi folks, > > We've had a phenomenal amount of discussion around 0-RTT anti-replay, > and based on my recent summary e-mails I think we generally agree > about the technical facts, so it's time to finalize the PR and land it > in the specification. > > > Here's what I propose to do: > > - Describe the attacks that Colm described. > > - Distinguish between replay and retransmission > > - Mandate (SHOULD-level) that servers do some sort of bounded > (at-most-N times) anti-replay mechanism and emphasize that > implementations that forbid replays entirely (only allowing > retransmission) are superior. > > - Describe the stateless mechanism as a recommended behavior but not > as a substitute for the other mechanisms. As Martin Thomson has > pointed out, it's a nice pre-filter for either of these other > mechanisms. > > - Clarify the behavior you need to get PFS. > > - Require (MUST) that clients only send and servers only accept "safe" > requests in 0-RTT, but allow implementations to determine what is > safe. > > Note: there's been a lot of debate about exactly where this stuff > should go in the document and how it should be phrased. I think these > are editorial questions and so largely my discretion. > > > Here's what I do not intend to do. > > - Mandate (MUST-level) any anti-replay mechanism. I do not believe > there is any WG consensus for this. > > - Design a mechanism to allow the server to tell the client that it > either (a) enforces strong anti-replay or (b) deletes PSKs after > first use. Either of these seem like OK ideas, but they can be added > to NST as extensions at some future time, and I haven't seen a lot > of evidence that existing clients would consume these. > > I recognize that nobody will be entirely happy with this, but I > believe it most closely represents consensus. Assuming the chairs > agree, I'd like to suggest a brief period of discussion on this > proposal, followed by a consensus call, and then I'll generate a PR > that enacts it. People will still have time to review that, but in > order to avoid an endless round of dicussion, the idea will be able to > review it for conformance to these principles, not to re-litigate > these. > > -Ekr > > Thank you for taking time to summarize this! All of those seem good to me. I am not sure "retransmission" is a good term here, since it can be easily confused with the TCP/QUIC-level retransmissions. -- Victor. --001a114a7e8c007ae70551dd388b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On S= un, Jun 11, 2017 at 11:18 AM, Eric Rescorla <ekr@rtfm.com> wrot= e:
Hi folks,
<= div>
We've had a phenomenal amount of discussion around 0= -RTT anti-replay,
and based on my recent summary e-mails I think = we generally agree
about the technical facts, so it's time to= finalize the PR and land it
in the specification.

=

Here's what I propose to do:

- Describe the attacks that Colm described.

- Distinguish between replay and retransmission

- Mandate (SHOULD-level) that servers do some sort of bounded
= =C2=A0 (at-most-N times) anti-replay mechanism and emphasize that
=C2=A0 implementations that forbid replays entirely (only allowing
=C2=A0 retransmission) are superior.

- Describe= the stateless mechanism as a recommended behavior but not
=C2=A0= as a substitute for the other mechanisms. As Martin Thomson has
= =C2=A0 pointed out, it's a nice pre-filter for either of these other
=C2=A0 mechanisms.

- Clarify the behavior = you need to get PFS.

- Require (MUST) that clients= only send and servers only accept "safe"
=C2=A0 reques= ts in 0-RTT, but allow implementations to determine what is
=C2= =A0 safe.

Note: there's been a lot of debate a= bout exactly where this stuff
should go in the document and how i= t should be phrased.=C2=A0 I think these
are editorial questions = and so largely my discretion.


Here&= #39;s what I do not intend to do.

- Mandate (MUST-= level) any anti-replay mechanism. I do not believe
=C2=A0 there i= s any WG consensus for this.

- Design a mechanism = to allow the server to tell the client that it
=C2=A0 either (a) = enforces strong anti-replay or (b) deletes PSKs after
=C2=A0 firs= t use. Either of these seem like OK ideas, but they can be added
= =C2=A0 to NST as extensions at some future time, and I haven't seen a l= ot
=C2=A0 of evidence that existing clients would consume these.<= /div>

I recognize that nobody will be entirely happy wit= h this, but I
believe it most closely represents consensus. Assum= ing the chairs
agree, I'd like to suggest a brief period of d= iscussion on this
proposal, followed by a consensus call, and the= n I'll generate a PR
that enacts it. People will still have t= ime to review that, but in
order to avoid an endless round of dic= ussion, the idea will be able to
review it for conformance to the= se principles, not to re-litigate
these.

-Ekr


Thank you for taking time to summarize this!

All of those seem goo= d to me.=C2=A0 I am not sure "retransmission" is a good term here= , since it can be easily confused with the TCP/QUIC-level retransmissions.<= /div>

=C2=A0= -- Victor.
--001a114a7e8c007ae70551dd388b-- From nobody Tue Jun 13 13:51:24 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9AD561200C5 for ; Tue, 13 Jun 2017 13:51:22 -0700 (PDT) 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, RP_MATCHES_RCVD=-0.001, URIBL_BLOCKED=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 LToMu4krvtaJ for ; Tue, 13 Jun 2017 13:51:20 -0700 (PDT) Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id 33500126E3A for ; Tue, 13 Jun 2017 13:51:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id A89E06366C; Tue, 13 Jun 2017 23:51:18 +0300 (EEST) 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 aiXgksPC227f; Tue, 13 Jun 2017 23:51:18 +0300 (EEST) 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 213D8288; Tue, 13 Jun 2017 23:51:18 +0300 (EEST) Date: Tue, 13 Jun 2017 23:51:13 +0300 From: Ilari Liusvaara To: Bill Cox Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613113232.GC8983@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: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 20:51:23 -0000 On Tue, Jun 13, 2017 at 12:06:26PM -0700, Bill Cox wrote: > On Tue, Jun 13, 2017 at 4:32 AM, Ilari Liusvaara > wrote: > > > Also: > > > > - Note that 0-RTT exporters are not safe for authentication unless > > the server does global anti-replay on 0-RTT. > > > I do not think this is the case. Nick Harper has proposed an RFC for token > binding over 0-RTT: > > - Note that 0-RTT exporters are not safe for authentication on servers > that do not enforce single-use tickets, or for clients that do not > recompute authentication signatures on retransmission of early data. "Single-use tickets" imply global anti-replay. And the latter part is way too obscure. I have no idea how it is trying to fix ClientHello replay resulting the same exporter output. E.g., for Triple Handshake, one can mitigate the vulernability for using the exporter outputs for authentication, but the EMS spec does not document the methods of doing this for good reasons. > Even this is only partially true. Anti-replay can be built above the TLS > layer. I'm considering doing token-binding replay defense in the > authentication backend, to help ensure the token-binding guarantee: that > auth tokens taken from one device cannot be used from another device > without continued access to the first device's signing oracle. > Unfortunately, 0-RTT master resumption secrets are a new kind of auth > bearer token, and the token binding spec does not cover them. Doing stuff like this gets more and more complicated and fragile as one moves up the layer stack. -Ilari From nobody Tue Jun 13 13:55:39 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77E86129AA0 for ; Tue, 13 Jun 2017 13:55:38 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 OlYcK9IC71Z3 for ; Tue, 13 Jun 2017 13:55:36 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id B4F6112922E for ; Tue, 13 Jun 2017 13:55:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 8311C2A55E; Tue, 13 Jun 2017 23:55:35 +0300 (EEST) 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 dflZpn2MV697; Tue, 13 Jun 2017 23:55:35 +0300 (EEST) 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 42A3327B; Tue, 13 Jun 2017 23:55:35 +0300 (EEST) Date: Tue, 13 Jun 2017 23:55:30 +0300 From: Ilari Liusvaara To: Andrei Popov Cc: Benjamin Kaduk , Colm =?utf-8?Q?MacC=C3=A1rthaigh?= , "tls@ietf.org" Message-ID: <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> 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: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 20:55:38 -0000 On Tue, Jun 13, 2017 at 06:57:05PM +0000, Andrei Popov wrote: > Regarding RFC language, I think we could be more specific: > > > > 1. A TLS implementation SHOULD/MUST only send 0-RTT application data if the application has explicitly opted in; > > 2. A TLS implementation SHOULD/MUST only accept 0-RTT application data if the application has explicitly opted in; > > 3. When delivering 0-RTT application data to the application, a TLS implementation SHOULD/MUST provide a way for the application to distinguish it from the rest of the application data. First of these has to be MUST, or you get problems like I outlined earlier. And to implement checking for client only sending "safe" data, you need the second and third. -Ilari From nobody Tue Jun 13 15:24:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A69131A1E for ; Tue, 13 Jun 2017 15:24:29 -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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 A76gxYpvUBcq for ; Tue, 13 Jun 2017 15:24:26 -0700 (PDT) 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 BE2F2131A0B for ; Tue, 13 Jun 2017 15:24:26 -0700 (PDT) Received: by mail-yb0-x22b.google.com with SMTP id 4so39856485ybl.1 for ; Tue, 13 Jun 2017 15:24:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=m3WU9w6Tr8JBwMJI7k85a/+f8ryEqUSfV6y2dCGg77E=; b=nXdw8VhGms61kghfVsBzXPkA7d0bA2w93iOYhikxHxOTvskan0tINhggIL8H4f8KDY qbochCEJJqknEDHpS7mXhwGw2Lp5bmft3KkcKvuausPii8aYjtIbSPwITXM/alDDJ4zw d/cuu0zrBZJdeyFiKZIq6tNZkaXx8Md2NbH+qfwkD+TqCNDwNKRO1q/mUFLXoQ39q/0E UDlzuLtC1dpeIcoiM/PUOaX2soaezzhizDPvGrlu/UuhJnWgceKKE660I7NZYeUV57Cr wPzkeN6g55KLMaxUMkkyWe/I2Jtf+4cED03J6ZRoYV2GxJkiGjwnXcVCb2bA41wme0XM YoBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=m3WU9w6Tr8JBwMJI7k85a/+f8ryEqUSfV6y2dCGg77E=; b=rt+aVDK9Qoy7/fpXF4RwuRbwiZcOGj8u8Tkqyo2OJZGuImu85QKw1N8awbx/SM4ZME 1JmxyadLfBf/ZJXc44Hx5mMeGYSe2+FoKuXxEMDQdK22r68GDYD4xkQLWQAUdooq9W8c yReShEhXqDcApQ/zqIpWEhxcTXdpYFFhq2gzC077/DL0jiyeStFYJGePTFskJ+YH6daj C0unXw9HWywL4B2gMAwN8l8/O+ccFfEXNnKSiCZsP3IRthqfkf1Q2lKuZqFpejdl5ptg 3pCfvJJv8FsEy1DPo1Z/MwfGLp74k2ePxhY1hNbSbugn45duBJAFpEJmuIdAonF+IF2G TFUQ== X-Gm-Message-State: AKS2vOzjzQLv55AEUD07GgsivgMXbSx3/eBJlgG9vnVYsxTyYD9UJNoT nKCnMMcX1NHgZ4fKlc3apuw0wCiOnBB1 X-Received: by 10.37.165.98 with SMTP id h89mr4829394ybi.10.1497392665778; Tue, 13 Jun 2017 15:24:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.222.67 with HTTP; Tue, 13 Jun 2017 15:24:24 -0700 (PDT) In-Reply-To: <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> From: Bill Cox Date: Tue, 13 Jun 2017 15:24:24 -0700 Message-ID: To: Ilari Liusvaara Cc: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c19f018ef77780551dee55f" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 13 Jun 2017 22:24:29 -0000 --94eb2c19f018ef77780551dee55f Content-Type: text/plain; charset="UTF-8" On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara wrote: > > - Note that 0-RTT exporters are not safe for authentication on servers > > that do not enforce single-use tickets, or for clients that do not > > recompute authentication signatures on retransmission of early data. > > "Single-use tickets" imply global anti-replay. > I assumed "gobal anti-replay" meant there would be a globally synchronized cache of valid single-use tickets. It sounds like you mean "global anti-replay" includes schemes using orbit/metro/server bound tickets, since they can support single-use tickets. In that case, I agree with you, but I think the phrase "single-use tickets" may be less confusing. Maybe just say "anti-replay" instead of "global anti-replay"? And the latter part is way too obscure. I have no idea how it is > trying to fix ClientHello replay resulting the same exporter > output. > I don't know what you mean by "resulting the same exporter output." Auth signatures in a 1-RTT fallback need to be recomputed using the 1-RTT exporter to avoid having the same signature accepted twice. Maybe this is too specific and should be left out. > Even this is only partially true. Anti-replay can be built above the TLS > > layer. I'm considering doing token-binding replay defense in the > > authentication backend, to help ensure the token-binding guarantee: that > > auth tokens taken from one device cannot be used from another device > > without continued access to the first device's signing oracle. > > Unfortunately, 0-RTT master resumption secrets are a new kind of auth > > bearer token, and the token binding spec does not cover them. > > Doing stuff like this gets more and more complicated and fragile as > one moves up the layer stack. > It depends on the task. Moving channel ID from the TLS layer to token binding in the HTTP layer should simplify the TLS state machine enough to justify the change. Anti-replay in the TLS layer would be good for 0-RTT token binding, but the cost and complexity of running the whole user-facing fleet of servers with anti-replay caches is huge, many times higher than the cost of token-binding anti-replay in the backend. Also, the authentication backend is where bound tokens are currently verified, so putting the anti-replay there seems like the appropriate layer. I'm still not sure this scheme is worth implementing, but without it, I do not think we can support client certificates or token binding over 0-RTT. It doesn't really matter for the TLS 1.3 spec. I'm just pointing out that the statement "0-RTT auth is insecure without anti-replay defense" is not 100% accurate. There are other ways to improve the security. Bill --94eb2c19f018ef77780551dee55f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On T= ue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara <ilariliusvaara@welho= .com> wrote:
>=C2=A0 =C2=A0- Note that 0-RTT exporters ar= e not safe for authentication on servers
> that do not enforce single-use tickets, or for clients that do not
> recompute authentication signatures on retransmission of early data.
"Single-use tickets" imply global anti-replay.

I assumed "gobal anti-replay" meant ther= e would be a globally synchronized cache of valid single-use tickets.=C2=A0= It sounds like you mean "global anti-replay" includes schemes us= ing orbit/metro/server bound tickets, since they can support single-use tic= kets.=C2=A0 In that case, I agree with you, but I think the phrase "si= ngle-use tickets" may be less confusing.=C2=A0 Maybe just say "an= ti-replay" instead of "global anti-replay"?

And the latter part is way too obscure. I have no idea how it is
trying to fix ClientHello replay resulting the same exporter
output.

I don't know what you mean = by "resulting the same exporter output." =C2=A0Auth signatures in= a 1-RTT fallback need to be recomputed using the 1-RTT exporter to avoid h= aving the same signature accepted twice.=C2=A0 Maybe this is too specific a= nd should be left out.

> Even this is only partially true.=C2=A0 Anti-replay can be built above= the TLS
> layer.=C2=A0 I'm considering doing token-binding replay defense in= the
> authentication backend, to help ensure the token-binding guarantee: th= at
> auth tokens taken from one device cannot be used from another device > without continued access to the first device's signing oracle.
> Unfortunately, 0-RTT master resumption secrets are a new kind of auth<= br> > bearer token, and the token binding spec does not cover them.

Doing stuff like this gets more and more complicated and fragile as<= br> one moves up the layer stack.

It depend= s on the task.=C2=A0 Moving channel ID from the TLS layer to token binding = in the HTTP layer should simplify the TLS state machine enough to justify t= he change.=C2=A0 Anti-replay in the TLS layer would be good for 0-RTT token= binding, but the cost and complexity of running the whole user-facing flee= t of servers with anti-replay caches is huge, many times higher than the co= st of token-binding anti-replay in the backend.=C2=A0 Also, the authenticat= ion backend is where bound tokens are currently verified, so putting the an= ti-replay there seems like the appropriate layer.

= I'm still not sure this scheme is worth implementing, but without it, I= do not think we can support client certificates or token binding over 0-RT= T.=C2=A0 It doesn't really matter for the TLS 1.3 spec.=C2=A0 I'm j= ust pointing out that the statement "0-RTT auth is insecure without an= ti-replay defense" is not 100% accurate.=C2=A0 There are other ways to= improve the security.

Bill
--94eb2c19f018ef77780551dee55f-- From nobody Tue Jun 13 23:17:35 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D687129B33 for ; Tue, 13 Jun 2017 23:17:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.001 X-Spam-Level: X-Spam-Status: No, score=-7.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_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_ZE7lfS4Nop for ; Tue, 13 Jun 2017 23:17:32 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (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 4E82F129B31 for ; Tue, 13 Jun 2017 23:17:32 -0700 (PDT) Received: from [192.168.3.123] (unknown [95.82.146.6]) by mail.nic.cz (Postfix) with ESMTPSA id 551F06017F for ; Wed, 14 Jun 2017 08:17:30 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1497421050; bh=wPFAyMSJDNTLYtTihUQMvdCuvo0m9FT7XIUpcAZd91A=; h=To:From:Date; b=r2s4NZbaSn/p1YFQZfIwRuasl3d3TzZWCk5Y/eA7hWnpJeDgbHDXIZeGyS/6ptTo0 B5RAuOnLhuV7FgNEBGbqegG4FqINegtosY4x4qQORn7KgdJPuvSuOzn/UJgxy6lpYy 3a8DVcT9w+7hROSoh8wOS60M/UiO/5GN6xmUnzu8= To: tls@ietf.org References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= Organization: CZ.NIC Message-ID: Date: Wed, 14 Jun 2017 08:17:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 06:17:34 -0000 On 13.6.2017 22:55, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 06:57:05PM +0000, Andrei Popov wrote: >> Regarding RFC language, I think we could be more specific: >> >> >> >> 1. A TLS implementation SHOULD/MUST only send 0-RTT application data if the application has explicitly opted in; >> >> 2. A TLS implementation SHOULD/MUST only accept 0-RTT application data if the application has explicitly opted in; >> >> 3. When delivering 0-RTT application data to the application, a TLS implementation SHOULD/MUST provide a way for the application to distinguish it from the rest of the application data. > > First of these has to be MUST, or you get problems like I outlined > earlier. > > And to implement checking for client only sending "safe" data, you need > the second and third. I support MUST for the three points above. -- Petr Špaček @ CZ.NIC From nobody Wed Jun 14 10:45:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88065120726 for ; Wed, 14 Jun 2017 10:45:41 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 BWqheivN-2Ut for ; Wed, 14 Jun 2017 10:45:38 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9C61201F2 for ; Wed, 14 Jun 2017 10:45:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id D01362A474; Wed, 14 Jun 2017 20:45:36 +0300 (EEST) 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 4jkuBc9LrSqh; Wed, 14 Jun 2017 20:45:36 +0300 (EEST) 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 7D485C4; Wed, 14 Jun 2017 20:45:36 +0300 (EEST) Date: Wed, 14 Jun 2017 20:45:31 +0300 From: Ilari Liusvaara To: Bill Cox Cc: Eric Rescorla , "tls@ietf.org" Message-ID: <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <20170613205113.GA13223@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: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 17:45:41 -0000 On Tue, Jun 13, 2017 at 03:24:24PM -0700, Bill Cox wrote: > On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara > wrote: > > > > - Note that 0-RTT exporters are not safe for authentication on servers > > > that do not enforce single-use tickets, or for clients that do not > > > recompute authentication signatures on retransmission of early data. > > > > "Single-use tickets" imply global anti-replay. > > > > I assumed "gobal anti-replay" meant there would be a globally synchronized > cache of valid single-use tickets. It sounds like you mean "global > anti-replay" includes schemes using orbit/metro/server bound tickets, since > they can support single-use tickets. In that case, I agree with you, but I > think the phrase "single-use tickets" may be less confusing. Maybe just > say "anti-replay" instead of "global anti-replay"? IMO, "anti-replay" also includes per-server anti-replay, which archives "at most N replays" in global scale. Of course, the ticket scope of server can be wider than the 0-RTT scope (the server accepts tickets but rejects 0-RTT from any ticket in between). > And the latter part is way too obscure. I have no idea how it is > > trying to fix ClientHello replay resulting the same exporter > > output. > > > > I don't know what you mean by "resulting the same exporter output." Auth > signatures in a 1-RTT fallback need to be recomputed using the 1-RTT > exporter to avoid having the same signature accepted twice. Maybe this is > too specific and should be left out. If you replay ClientHello and it gets accepted twice, including to different servers, both connections have the same 0-RTT exporter values. The 1-RTT exporter values will not be the same, but this is not helpful for 0-RTT data, or for that matter any 1-RTT data unless exporters are switched mid-stream. > > Even this is only partially true. Anti-replay can be built above the TLS > > > layer. I'm considering doing token-binding replay defense in the > > > authentication backend, to help ensure the token-binding guarantee: that > > > auth tokens taken from one device cannot be used from another device > > > without continued access to the first device's signing oracle. > > > Unfortunately, 0-RTT master resumption secrets are a new kind of auth > > > bearer token, and the token binding spec does not cover them. > > > > Doing stuff like this gets more and more complicated and fragile as > > one moves up the layer stack. > > > > It depends on the task. Moving channel ID from the TLS layer to token > binding in the HTTP layer should simplify the TLS state machine enough to > justify the change. Implementing such thing without some TLS support at application layer is just crazy. IMO, the only reason token binding concerns itself at all with TLS is that "0.5 RTT" (a TLS 1.3 feature) and HTTP/2 was not available when token binding was started. Those (together with exporters) would have enabled token binding in HTTPS without having to mess with TLS. (The messing with TLS in token binding seems to be solely about saving round-trips!) > Anti-replay in the TLS layer would be good for 0-RTT > token binding, but the cost and complexity of running the whole user-facing > fleet of servers with anti-replay caches is huge, many times higher than > the cost of token-binding anti-replay in the backend. Also, the > authentication backend is where bound tokens are currently verified, so > putting the anti-replay there seems like the appropriate layer. That greatly depends on the implementation and deployment. That's why it is more fragile. E.g. run more than one authentication backend for 0-RTT scope, and your application layer anti-replay breaks. And I'm not convinced the scale of anti-replay cache would be much smaller at application layer, in fact, it could be even biger. > I'm still not sure this scheme is worth implementing, but without it, I do > not think we can support client certificates or token binding over 0-RTT. > It doesn't really matter for the TLS 1.3 spec. I'm just pointing out that > the statement "0-RTT auth is insecure without anti-replay defense" is not > 100% accurate. There are other ways to improve the security. Well, client certificates are currently forbidden for connections with 0-RTT data (indirectly, but it is still forbidden). It could become possible in the future. -Ilari From nobody Wed Jun 14 11:00:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E6DE1272E1 for ; Wed, 14 Jun 2017 11:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.102 X-Spam-Level: X-Spam-Status: No, score=-7.102 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, RCVD_IN_MSPIKE_H2=-2.8, RP_MATCHES_RCVD=-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=apple.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 P4mcfsE7LVfq for ; Wed, 14 Jun 2017 11:00:17 -0700 (PDT) Received: from mail-in3.euro.apple.com (mail-in.euro.apple.com [17.72.148.13]) (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 998F41201F2 for ; Wed, 14 Jun 2017 11:00:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497463215; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=7ZnTBLvB7Y7aJk0B+Nl1LyFA5OVh7wLphGfZGPqhVsw=; b=NSQ+btOFMEq+xRFzLkiAKMsbYVpWMCyuV6GixhgnuuDYwH+wU7dcTddGIZUIDwgX 4Z7x36PtRJpQ2LzfMu76KVVzvxUdWzN6Uwguthio0QuW5j9/prKnB+a6wgdvQYE5 oPIzaUHNpEgw8/Qv6W9JgCDtItzdoyr2ooYbavVZIIB8EGL2oV78eaRYPaaR1hOZ MX0ZWljnd6241aI4rjj6LKMXoUK78BWf0ZpUx1DXl8K817jqRzfCMu+PCJtnDc01 V0GHVG6LH+f6tvgi3MgbDFoOwkAWA1f3TsEqOYh7ofeIrXPElaCM8dMiynhjcZZ8 YBL9yEH46awkeX1JfOMNcg==; Received: from relay2.euro.apple.com ( [17.66.55.12]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in3.euro.apple.com (Symantec Mail Security) with SMTP id 45.9B.20605.FA971495; Wed, 14 Jun 2017 19:00:15 +0100 (BST) X-AuditID: 1148940d-98d8b9a00000507d-a3-594179af40fa Received: from crk-phonehomebzp-sz03.euro.apple.com ( [17.72.133.83]) by relay2.euro.apple.com (Symantec Mail Security) with SMTP id 56.5F.20702.DA971495; Wed, 14 Jun 2017 19:00:14 +0100 (BST) MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Received: from [17.235.208.34] (unknown [17.235.208.34]) by phonehome3.euro.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170222 64bit (built Feb 22 2017)) with ESMTPSA id <0ORJ00KULU0CPE20@phonehome3.euro.apple.com> for tls@ietf.org; Wed, 14 Jun 2017 19:00:13 +0100 (IST) Sender: cawood@apple.com From: Chris Wood Content-transfer-encoding: quoted-printable Message-id: <0E6B6240-4F99-46D4-81D0-533473EBFD87@apple.com> Date: Wed, 14 Jun 2017 20:00:10 +0200 To: tls@ietf.org X-Mailer: Apple Mail (2.3434) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNLMWRmVeSWpSXmKPExsUi6GTOo7u+0jHS4MpzdYtP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMa93FWPBZdaK1jmT2RsYT7B0MXJySAiYSLQcOczaxcjFISSw iEniYu9fJpjE44MdLBCJQ4wSN94+YQRJ8AoISvyYfA8owcHBLKAuMWVKLkTNMiaJF63/mEFq hAUkJF7vmQhmswkoS1w4uJAdxGYW0JZ48u4CK0SNvMTRd7egZtpIfLvdBHYRi4CqxKvHe9lA 5osICEg0vxQDMSUEZCWefjQEWSUhcJFVYv/vNtYJjAKzkFw0C+GiWUiWLWBkXsUonpuYmaOb mWesl1palK+XWFCQk6qXnJ+7iREUhB5TeHcwXj9oeIhRgINRiYf3VL5jpBBrYllxZS7Q5xzM SiK8VhVAId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rwmpfKRQgLpiSWp2ampBalFMFkmDk6pBsbF b39HHlfdvsVH6TofR7pOlVxb3ye1xx1Z33izWbdO331yHleR8buinaq1C+19a2b+vZa7VPZc uvTFO89YOTu3OtU9eqetLerA8sx4z/zcg6IlU1wNCuIsZH7GG7odjvn5RvZPzqNt3XMmqHE/ mx03VXm1mc6WBya7ufZ1fvh2McCwwpdveZwSS3FGoqEWc1FxIgBghWCSPgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpmluLIzCtJLcpLzFFi42IR9GgN1l1X6Rhp0P9T3+LT+S5GB0aPJUt+ MgUwRnHZpKTmZJalFunbJXBlzOtdxVhwmbWidc5k9gbGEyxdjJwcEgImEo8PdgDZXBxCAocY JW68fcIIkuAVEJT4MfkeUIKDg1lAXWLKlFyImmVMEi9a/zGD1AgLSEi83jMRzGYTUJa4cHAh O4jNLKAt8eTdBVaIGnmJo+9uQc20kfh2uwlsMYuAqsSrx3vZQOaLCAhINL8UAzElBGQlnn40 nMDIOwvJEbMQjpiFZP4CRuZVjKJFqTmJlUZ6qaVF+XqJBQU5qXrJ+bmbGEFB42TOs4Px1UHD Q4wCHIxKPLzv8hwjhVgTy4orc4Fe5WBWEuG1qgAK8aYkVlalFuXHF5XmpBYfYpTmYFES5y09 ei5CSCA9sSQ1OzW1ILUIJsvEwSnVwMiuXTqpRT7xC9u0RcGafWkh00NefVt6YOH/5ZJOffP3 3pzDJj51ucNTqb3BRSkpU/wUw7lVNM5Nm7vkbt8WSbXuaO2ru3gCD8/gqP0S86Dr+Vf9JOGH Cqu22LjuLfN4dnBqfM2x9Qzfso7knut58msH962fj9r0fs1LPu4WXl6+z0Rh3eF1oSuVWIoz Eg21mIuKEwGUg2EVFgIAAA== Archived-At: Subject: [TLS] TLS 1.3 (-18) at Apple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 18:00:19 -0000 Hi folks, Last week at WWDC 2017, we (Apple) announced support for TLS 1.3 (-18) = in our platforms. It is not turned on by default. If you=E2=80=99re a = member of the developer seed, you may enable it on iOS by downloading = and installing the following profile: https://developer.apple.com/go/?id=3Dtls13-mobile-profile You may also enable support on macOS with the following defaults write: defaults write /Library/Preferences/com.apple.networkd = tcp_connect_enable_tls13 1 Our goal is maximal coverage in apps and networks. We encourage everyone = who=E2=80=99s a member to opt in and start testing your services.=20 Note, we currently do not have 0-RTT data support. Best, Chris= From nobody Wed Jun 14 11:03:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA33C1272E1 for ; Wed, 14 Jun 2017 11:02:59 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 4XjAZ5GyGarm for ; Wed, 14 Jun 2017 11:02:57 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 EB6F0129413 for ; Wed, 14 Jun 2017 11:02:57 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5EI2K9d015595; Wed, 14 Jun 2017 19:02:53 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=kEzm1o9vLLG/f8F3b2eHMv11PaD1U5kDCuDIptXvmSQ=; b=Iiig+cLiltf3knEa/aVwsJUSHTNsVgqb/9DecJJelYDtwsOyTfAi+21z9Soh1hjP5zXe m0AziUqaSuUTXEgzykhWJr6PPRHb3+djTr7txXWK2pPAvAudvXyVS5VGutkCJsYsVUHU wLn/rRxBlPxF/StEZpcC1VesxG6CQ0VLppgB50QDkuSV5SWg5JbgCw/h816gJU5B83sj /3ik1VOL0MyFRyps7tVo8z/gZ47KVMEevU3PiU+pHQXJGE43rrZ7ZIc7mFXSbgmbWE54 CIOqcxnTeVFYrg3eRLBRln14IrpDQj1iRi7fjerzBIhWGiXB/yqZi49ZUl/q42mHT6ee Jg== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050093.ppops.net-00190b01. with ESMTP id 2b37jvs2yf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 19:02:53 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5EI16iG004727; Wed, 14 Jun 2017 14:02:52 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b0c3v2yy2-1; Wed, 14 Jun 2017 14:02:52 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 569B620064; Wed, 14 Jun 2017 12:02:52 -0600 (MDT) To: Chris Wood , tls@ietf.org References: <0E6B6240-4F99-46D4-81D0-533473EBFD87@apple.com> From: Benjamin Kaduk Message-ID: Date: Wed, 14 Jun 2017 13:02:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: <0E6B6240-4F99-46D4-81D0-533473EBFD87@apple.com> Content-Type: multipart/alternative; boundary="------------187A2B66A8BCCE5E25CFC8DE" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-14_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140300 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-14_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140301 Archived-At: Subject: Re: [TLS] TLS 1.3 (-18) at Apple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 18:03:00 -0000 This is a multi-part message in MIME format. --------------187A2B66A8BCCE5E25CFC8DE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/14/2017 01:00 PM, Chris Wood wrote: > Hi folks, > > Last week at WWDC 2017, we (Apple) announced support for TLS 1.3 (-18) in our platforms. It is not turned on by default. If you’re a member of the developer seed, you may enable it on iOS by downloading and installing the following profile: > > https://developer.apple.com/go/?id=tls13-mobile-profile > > You may also enable support on macOS with the following defaults write: > > defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1 Is the plan to stay on draft-18 until it's time to move to the final RFC version? > Our goal is maximal coverage in apps and networks. We encourage everyone who’s a member to opt in and start testing your services. > > Note, we currently do not have 0-RTT data support. > Seems prudent, given how much it's still in flux (and the lack of published application profiles for its use). -Ben --------------187A2B66A8BCCE5E25CFC8DE Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/14/2017 01:00 PM, Chris Wood wrote:
Hi folks,

Last week at WWDC 2017, we (Apple) announced support for TLS 1.3 (-18) in our platforms. It is not turned on by default. If you’re a member of the developer seed, you may enable it on iOS by downloading and installing the following profile:

    https://developer.apple.com/go/?id=tls13-mobile-profile

You may also enable support on macOS with the following defaults write:

    defaults write /Library/Preferences/com.apple.networkd tcp_connect_enable_tls13 1

Is the plan to stay on draft-18 until it's time to move to the final RFC version?

Our goal is maximal coverage in apps and networks. We encourage everyone who’s a member to opt in and start testing your services. 

Note, we currently do not have 0-RTT data support.

Seems prudent, given how much it's still in flux (and the lack of published application profiles for its use).

-Ben
--------------187A2B66A8BCCE5E25CFC8DE-- From nobody Wed Jun 14 11:09:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143B81292FD for ; Wed, 14 Jun 2017 11:09:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-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=apple.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 kvgg2RlFFDNA for ; Wed, 14 Jun 2017 11:09:06 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (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 36F43128AB0 for ; Wed, 14 Jun 2017 11:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1497463746; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=8XFNF35SLyLFBihiTkM4xbR6onfyGRq1hfxJ8Rhyr3o=; b=UQQXhzC2wM2JNvlgtISV3bARJyGk+wVtfCOshIV32fe4B5VdKgNg+Fp51ekYQSeA wQlM+kH0ugsjBOGrV5XY4/DQRqAeNQamhnSOXZpSVQEKebprNF2eRRix4wf5YCPP s1ANFbrClcM+JJCBQ+dZIVMGy5AA6XHfjq9g8NEbPNr8lMZr7fg4mxmY2E3qtwl7 LLT+lyaSwwLdz5EdNbZgWVj+oH7fdbQMT6CX83TYOF2h1X9pdKDa49ETOFsZ8lKD zkCQ0W/paG2SD+dY08jmRx6testx5S/cgbSac3KklhwmJP2FjiTqfUGdB+mBJBBg wjHjguLI1amYImLNv9in0w==; Received: from relay24.apple.com (relay24.apple.com [17.171.128.105]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 4B.DF.07949.1CB71495; Wed, 14 Jun 2017 11:09:06 -0700 (PDT) X-AuditID: 11973e16-bf3fb70000001f0d-4f-59417bc1f455 Received: from russet.apple.com (russet.apple.com [17.171.2.67]) by relay24.apple.com (Apple SCV relay) with SMTP id 2A.19.18906.0CB71495; Wed, 14 Jun 2017 11:09:04 -0700 (PDT) MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_JwaC84C52Z8AAw/+gFk7Dw)" Received: from [100.82.154.129] (228.sub-174-221-129.myvzw.com [174.221.129.228]) by russet.apple.com (Oracle Communications Messaging Server 8.0.1.2.20170210 64bit (built Feb 10 2017)) with ESMTPSA id <0ORJ008FXUF2S060@russet.apple.com>; Wed, 14 Jun 2017 11:09:04 -0700 (PDT) Sender: cawood@apple.com From: Chris Wood X-Mailer: iPhone Mail (14F89) In-reply-to: Date: Wed, 14 Jun 2017 20:09:01 +0200 Cc: tls@ietf.org Message-id: <13099025-10E2-42B8-B331-2FE84BC08473@apple.com> References: <0E6B6240-4F99-46D4-81D0-533473EBFD87@apple.com> To: Benjamin Kaduk X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUiuLohU/dQtWOkwbpWVovGzY2sFp/OdzE6 MHlMPrKA2WPJkp9MAUxRXDYpqTmZZalF+nYJXBkPHuUXLJetmL/wB2MD4zKJLkZODgkBE4mn T0+xdjFycQgJrGOSmHmgiwUmcb5vLxNEYhOjxNLmCcwgCV4BQYkfk++BFTELhElc+biQHaJo HpPE7h1bwYqEBSQkXu+ZCGVrSvyY9ZURxGYTUJa4cBCkAWSDrMTJle1ANgcHp4CdxL75IiBh FgFViYPPZrBDzBeQOPfsBdReG4knx++AxYUECiQWzlvBCtIqIqAmcWFeHcTECWwS51dJTGAU moXk0llILp0F1MEsoC4xZUouRFhb4sm7C6wQtprEwt+LmJDFFzCyrWIUyk3MzNHNzDPXSywo yEnVS87P3cQIioLpdmI7GB+usjrEKMDBqMTDy2DhGCnEmlhWXJl7iFGag0VJnHd5MVBIID2x JDU7NbUgtSi+qDQntfgQIxMHp1QDI8ODasUPoYu2u6hsMd4e52HuKlYv/fdO7cvvu9aodD35 +dOmwfNRRNTfnulPTi/bstlrTTOvdNeME+ZnHDm3BXKoH+yvsb9zd7lS1kWu44eDBTREJjie Ubr0cL5D3P/L3t8e3uqT5mi82/r9qWTzksCPok4ut/5Z51987332Stq9TVyzJio56CmxFGck GmoxFxUnAgBumAjOYwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrKLMWRmVeSWpSXmKPExsUiuJrJWfdAtWOkwcT5lhaNmxtZLT6d72J0 YPKYfGQBs8eSJT+ZApiiuGxSUnMyy1KL9O0SuDIePMovWC5bMX/hD8YGxmUSXYycHBICJhLn +/YydTFycQgJbGKUWNo8gRkkwSsgKPFj8j0WEJtZIEziyseF7BBF85gkdu/YClYkLCAh8XrP RChbU+LHrK+MIDabgLLEhYMgDSAbZCVOrmwHsjk4OAXsJPbNFwEJswioShx8NoMdYr6AxLln L6D22kg8OX4HLC4kUCCxcN4KVpBWEQE1iQvz6iYw8s9Cct0sJNfNAqpiFlCXmDIlFyKsLfHk 3QVWCFtNYuHvRUzI4gsY2VYxChal5iRWGpnoJRYU5KTqJefnbmIEB25D5g7GWzfNDjEKcDAq 8fCuMHWMFGJNLCuuzD3EKMHBrCTCa1UBFOJNSaysSi3Kjy8qzUktPsQozcGiJM7rAZISSE8s Sc1OTS1ILYLJMnFwSjUwpkz6v7fKsSdmRvxz1Qd79k6UvyP/f4lZq/i8adwTP8n698X6V6cH fnNnczN5wxhkEeSWmGczqfINY/puj0eqWkmXHb5ytF/YntK65vibEoUPpvcfmP7Td3zrdb3m UtLRm/zN7vrR8WV+iSJ1dlxnPvrU3kiou+Suyfza7HfVTNY5NTvvLTmpxFKckWioxVxUnAgA uXXKqlgCAAA= Archived-At: Subject: Re: [TLS] TLS 1.3 (-18) at Apple X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 18:09:08 -0000 --Boundary_(ID_JwaC84C52Z8AAw/+gFk7Dw) Content-type: text/plain; charset=utf-8 Content-transfer-encoding: quoted-printable > On Jun 14, 2017, at 8:02 PM, Benjamin Kaduk wrote: >=20 >> On 06/14/2017 01:00 PM, Chris Wood wrote: >> Hi folks, >>=20 >> Last week at WWDC 2017, we (Apple) announced support for TLS 1.3 (-18) in= our platforms. It is not turned on by default. If you=E2=80=99re a member o= f the developer seed, you may enable it on iOS by downloading and installing= the following profile: >>=20 >> https://developer.apple.com/go/?id=3Dtls13-mobile-profile >>=20 >> You may also enable support on macOS with the following defaults write: >>=20 >> defaults write /Library/Preferences/com.apple.networkd tcp_connect_en= able_tls13 1 >=20 > Is the plan to stay on draft-18 until it's time to move to the final RFC v= ersion? As of now, that is the most likely outcome. Though that may change if most o= ther clients and servers move to a more recent version. >> Our goal is maximal coverage in apps and networks. We encourage everyone w= ho=E2=80=99s a member to opt in and start testing your services.=20 >>=20 >> Note, we currently do not have 0-RTT data support. >>=20 >=20 > Seems prudent, given how much it's still in flux (and the lack of publishe= d application profiles for its use). Precisely.=20 Best, Chris=20 --Boundary_(ID_JwaC84C52Z8AAw/+gFk7Dw) Content-type: text/html; charset=utf-8 Content-transfer-encoding: quoted-printable

On Jun 14, 2017, at 8:0= 2 PM, Benjamin Kaduk <bkaduk@akamai.= com> wrote:

=20 =20 =20 On 06/14/2017 01:00 PM, Chris Wood wrote:
Hi folks,

Last week at WWDC 2017, we (Apple) announced support for TLS 1.3 (-18) in ou=
r platforms. It is not turned on by default. If you=E2=80=99re a member of t=
he developer seed, you may enable it on iOS by downloading and installing th=
e following profile:

    https://developer.apple.com/go/?id=3Dtls13-mob=
ile-profile

You may also enable support on macOS with the following defaults write:

    defaults write /Library/Preferences/com.apple.networkd tcp_connect_enabl=
e_tls13 1

Is the plan to stay on draft-18 until it's time to move to the final RFC version?

As of now, that i= s the most likely outcome. Though that may change if most other clients and s= ervers move to a more recent version.

=20 
Our goal is maximal coverage in apps and networks. We e=
ncourage everyone who=E2=80=99s a member to opt in and start testing your se=
rvices.=20

Note, we currently do not have 0-RTT data support.

Seems prudent, given how much it's still in flux (and the lack of published application profiles for its use).
=
Precisely. 

Best,
Chris 

= --Boundary_(ID_JwaC84C52Z8AAw/+gFk7Dw)-- From nobody Wed Jun 14 12:55:41 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9DBCB129544 for ; Wed, 14 Jun 2017 12:55:39 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 yyJxqFiYk216 for ; Wed, 14 Jun 2017 12:55:36 -0700 (PDT) Received: from mail-pg0-x22b.google.com (mail-pg0-x22b.google.com [IPv6:2607:f8b0:400e: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 C5FD312EB06 for ; Wed, 14 Jun 2017 12:55:36 -0700 (PDT) Received: by mail-pg0-x22b.google.com with SMTP id a70so4612818pge.3 for ; Wed, 14 Jun 2017 12:55:36 -0700 (PDT) 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=+MBnlnPmoXc4G8RTEBdDlC0mIfRvF5DbO5aZNWQhVYU=; b=V0azzHYjGyFhPPtMICmfidM+bP3kzn2QAyhxSuLoRgeRLT2pN7DXjNcGpaK+aPmNm2 kHobQyFaUHvXYaWm6BPzb9sWMmy5UT9OV2Q3QJyzl2/A6otgJe/vlSp59lslAio6f7n1 0k4GXS6yVQFxCwl6kuiXlRdF1WNf2EqdW52uk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=+MBnlnPmoXc4G8RTEBdDlC0mIfRvF5DbO5aZNWQhVYU=; b=S7IoUM17fBoxFGEpaqlHFWppV0fsCUr3gn+bXJnZIdU4s6doxdFlAe6Gp3/MCWpMSW eNnl5SnpdoZc5PbefIxTuK7bJLet6WZ2aTdlSGSh+lxAT8SWaFBkOdmV20wRTyhZhV7P G+6mFBOjWxQNdU1mP6MvQMYMa7dWqm4uTkEMBJmCBdkZZAKDDy4rzvVKITSbDJwDq/P6 Egeav94PAqUVtXIBYmGhokwR1JE8/tfY3dvn5c6dLX9INT0BV+LMJ2MLVjaB+r2o5gA5 MYrklJlJqu8weJGOofEJWw329WHyVv+HcenqAvlXN7iYr5II/suMLTsPOSKBxKL9fB+D 0kEQ== X-Gm-Message-State: AKS2vOwPJ2Oxyiu0koeDHFGnnS72f2kXKtfZrXUG5/3T+iaZgSU9+VPx v57bYITLbhmSsSUWbEsc8vJJCUyBuL6eZBs= X-Received: by 10.84.236.71 with SMTP id h7mr1830712pln.88.1497470136236; Wed, 14 Jun 2017 12:55:36 -0700 (PDT) MIME-Version: 1.0 References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: David Benjamin Date: Wed, 14 Jun 2017 19:55:24 +0000 Message-ID: To: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , tls@ietf.org Content-Type: multipart/alternative; boundary="f403045fe2e48899970551f0efb4" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 19:55:39 -0000 --f403045fe2e48899970551f0efb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 14, 2017 at 2:17 AM Petr =C5=A0pa=C4=8Dek = wrote: > > > On 13.6.2017 22:55, Ilari Liusvaara wrote: > > On Tue, Jun 13, 2017 at 06:57:05PM +0000, Andrei Popov wrote: > >> Regarding RFC language, I think we could be more specific: > >> > >> > >> > >> 1. A TLS implementation SHOULD/MUST only send 0-RTT application data i= f > the application has explicitly opted in; > >> > >> 2. A TLS implementation SHOULD/MUST only accept 0-RTT application data > if the application has explicitly opted in; > >> > >> 3. When delivering 0-RTT application data to the application, a TLS > implementation SHOULD/MUST provide a way for the application to distingui= sh > it from the rest of the application data. > > > > First of these has to be MUST, or you get problems like I outlined > > earlier. > > > > And to implement checking for client only sending "safe" data, you need > > the second and third. > > I support MUST for the three points above. > The third one is not practical as one moves up layers. Instead, I believe we can get the same benefit with a simpler signal. TLS fundamentally is a transformation from a vaguely TCP-like transport to another vaguely TCP-like transport. Consider TLS records: TLS could have decided record boundaries were meaningful and applications can use it in their framing layers, but instead TLS exposes a byte stream, because it intentionally looks like TCP. Of course, 0-RTT unavoidably must stretch the =E2=80=9Cvaguely=E2=80=9D. Su= ppose there is a semantically meaningful difference between 0-RTT and 1-RTT data. I can see why this is attractive. It moves the problem out of TLS. But this signal is pointless if applications don=E2=80=99t use it. If everyone did the followi= ng, we haven=E2=80=99t solved anything: if (InEarlyData()) { return EarlyDataRead(...); } else { return NormalRead(...); } So we must consider this signal=E2=80=99s uses. Consider HTTP/2. The goal m= ay be to tag requests as =E2=80=9C0-RTT=E2=80=9D, because we wish to reject 0-RTT PO= STs or so. What if the server receives data with the 0-RTT boundary spanning an HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid? If I=E2=80=99m parsing that= , I have to concatenate, and we=E2=80=99re back to that if/else strawman above. HTTP= 2 is arguably an easy case. Maybe my protocol is a compressed stream. Carrying a low-level byte boundary through layers of application data parsing and processing is not practical. We could say that the application profile should modify the protocol to reject such cases. Now, we=E2=80=99re taking on complexity in every protoco= l specification and parser. It also brings complexity on the sender side. Perhaps I am halfway through writing an HTTP/2 frame and, in parallel, I receive the ServerHello. We moved 0-RTT data out of a ClientHello extension way back in draft -07 so 0-RTT data can be streamed while waiting for ServerHello. This is especially useful for HTTP/2 where reads and writes flow in parallel. This means the sender must synchronize with the TLS socket to delay the 1-RTT transition. Now suppose the TLS stack receives that atomic data and it doesn=E2=80=99t = fit in the 0-RTT send limit. That won=E2=80=99t work, so the sender must query the= early data size and send over 1-RTT if it doesn=E2=80=99t fit. Now suppose this HTTP request takes multiple frames to send. One can send multiple HEADERS frames in HTTP/2. That won=E2=80=99t work, so we actually = need the synchronization to cover the entire request. Maybe my request has a response body. We need to cover that too, and we need to know the size for send limit purposes. Now suppose assembling the HTTP request takes an asynchronous step after connection binding. Maybe I=E2=80=99m signing something for tokbind. Maybe = I have some weird browser extension API. In this worldview, all the while, the HTTP/2 multiplexer must lock out all other requests and the client Finished, even if the ServerHello has already come in. That last one is particularly nasty if the server is delaying an already-sent request until the 1-RTT point (cf. https://www.ietf.org/mail-archive/web/tls/current/msg21486.html). Perhaps I keep the request assembling logic, HTTP/2 multiplexers, and TLS sockets in different threads or processes. Now this synchronization must span all of these. As one adds layers, the complexity grows. The root problem here is we=E2=80=99ve changed TLS=E2=80=99s core abstracti= on. One might argue all this complexity is warranted for 0-RTT. We are trying to solve a problem here. But I think we can solve it simpler: Our problem is a server wishes not to process some HTTP requests (or other protocol units) at 0-RTT and needs to detect this case. So check a boolean signal for whether the connection has currently passed the 1-RTT point before any unsafe processing. A =E2=80=9C1-RTT request=E2=80=9D will always= return 1-RTT. A =E2=80=9C0-RTT request=E2=80=9D will usually return 0-RTT, but if it spans = the boundary or the processing pipeline was just slow, perhaps we don=E2=80=99t query until= after the client Finished. That=E2=80=99s actually fine. We get the replay protec= tion we need out of the client Finished. This solves our problem without the complexity. Two APIs or an explicit boundary is one way to expose this boolean, but this boolean, unlike the hard boundary, is much easier to carry across higher-level protocol layers, and does not imply impractical sender constraints. David --f403045fe2e48899970551f0efb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 14= , 2017 at 2:17 AM Petr =C5=A0pa=C4=8Dek <petr.spacek@nic.cz> wrote:


On 13.6.2017 22:55, Ilari Liusvaara wrote:
> On Tue, Jun 13, 2017 at 06:57:05PM +0000, Andrei Popov wrote:
>> Regarding RFC language, I think we could be more specific:
>>
>>
>>
>> 1. A TLS implementation SHOULD/MUST only send 0-RTT application da= ta if the application has explicitly opted in;
>>
>> 2. A TLS implementation SHOULD/MUST only accept 0-RTT application = data if the application has explicitly opted in;
>>
>> 3. When delivering 0-RTT application data to the application, a TL= S implementation SHOULD/MUST provide a way for the application to distingui= sh it from the rest of the application data.
>
> First of these has to be MUST, or you get problems like I outlined
> earlier.
>
> And to implement checking for client only sending "safe" dat= a, you need
> the second and third.

I support MUST for the three points above.

The third one is not practical as one moves up layers. Instead, I believ= e we can get the same benefit with a simpler signal.
=C2=A0
=
TLS fundamentally is a transformation from a vaguely TCP-like transpor= t to another vaguely TCP-like transport. Consider TLS records: TLS could ha= ve decided record boundaries were meaningful and applications can use it in= their framing layers, but instead TLS exposes a byte stream, because it in= tentionally looks like TCP.
=C2=A0
Of course, 0-RTT una= voidably must stretch the =E2=80=9Cvaguely=E2=80=9D. Suppose there is a sem= antically meaningful difference between 0-RTT and 1-RTT data. I can see why= this is attractive. It moves the problem out of TLS. But this signal is po= intless if applications don=E2=80=99t use it. If everyone did the following= , we haven=E2=80=99t solved anything:
=C2=A0
if (InEarl= yData()) {
=C2=A0 return EarlyDataRead(...);
} else {
=C2=A0 return NormalRead(...);
}
=C2=A0
<= div>So we must consider this signal=E2=80=99s uses. Consider HTTP/2. The go= al may be to tag requests as =E2=80=9C0-RTT=E2=80=9D, because we wish to re= ject 0-RTT POSTs or so.
=C2=A0
What if the server recei= ves data with the 0-RTT boundary spanning an HTTP/2 frame? Is that a 0-RTT = request? 1-RTT? Invalid? If I=E2=80=99m parsing that, I have to concatenate= , and we=E2=80=99re back to that if/else strawman above. HTTP2 is arguably = an easy case. Maybe my protocol is a compressed stream. Carrying a low-leve= l byte boundary through layers of application data parsing and processing i= s not practical.
=C2=A0
We could say that the applicati= on profile should modify the protocol to reject such cases. Now, we=E2=80= =99re taking on complexity in every protocol specification and parser.
=C2=A0
It also brings complexity on the sender side. Perhap= s I am halfway through writing an HTTP/2 frame and, in parallel, I receive = the ServerHello. We moved 0-RTT data out of a ClientHello extension way bac= k in draft -07 so 0-RTT data can be streamed while waiting for ServerHello.= This is especially useful for HTTP/2 where reads and writes flow in parall= el. This means the sender must synchronize with the TLS socket to delay the= 1-RTT transition.
=C2=A0
Now suppose the TLS stack rec= eives that atomic data and it doesn=E2=80=99t fit in the 0-RTT send limit. = That won=E2=80=99t work, so the sender must query the early data size and s= end over 1-RTT if it doesn=E2=80=99t fit.
=C2=A0
Now su= ppose this HTTP request takes multiple frames to send. One can send multipl= e HEADERS frames in HTTP/2. That won=E2=80=99t work, so we actually need th= e synchronization to cover the entire request. Maybe my request has a respo= nse body. We need to cover that too, and we need to know the size for send = limit purposes.
=C2=A0
Now suppose assembling the HTTP = request takes an asynchronous step after connection binding. Maybe I=E2=80= =99m signing something for tokbind. Maybe I have some weird browser extensi= on API. In this worldview, all the while, the HTTP/2 multiplexer must lock = out all other requests and the client Finished, even if the ServerHello has= already come in. That last one is particularly nasty if the server is dela= ying an already-sent request until the 1-RTT point (cf. https://www.ietf.o= rg/mail-archive/web/tls/current/msg21486.html).
=C2=A0
<= div>Perhaps I keep the request assembling logic, HTTP/2 multiplexers, and T= LS sockets in different threads or processes. Now this synchronization must= span all of these. As one adds layers, the complexity grows.
=C2= =A0
The root problem here is we=E2=80=99ve changed TLS=E2=80=99s = core abstraction. One might argue all this complexity is warranted for 0-RT= T. We are trying to solve a problem here. But I think we can solve it simpl= er:
=C2=A0
Our problem is a server wishes not to proces= s some HTTP requests (or other protocol units) at 0-RTT and needs to detect= this case. So check a boolean signal for whether the connection has curren= tly passed the 1-RTT point before any unsafe processing. A =E2=80=9C1-RTT r= equest=E2=80=9D will always return 1-RTT. A =E2=80=9C0-RTT request=E2=80=9D= will usually return 0-RTT, but if it spans the boundary or the processing = pipeline was just slow, perhaps we don=E2=80=99t query until after the clie= nt Finished. That=E2=80=99s actually fine. We get the replay protection we = need out of the client Finished.
=C2=A0
This solves our= problem without the complexity. Two APIs or an explicit boundary is one wa= y to expose this boolean, but this boolean, unlike the hard boundary, is mu= ch easier to carry across higher-level protocol layers, and does not imply = impractical sender constraints.

David<= /div>
--f403045fe2e48899970551f0efb4-- From nobody Wed Jun 14 14:01:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07DB1275AB for ; Wed, 14 Jun 2017 14:01:14 -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 mkUg3xvNQvug for ; Wed, 14 Jun 2017 14:01:11 -0700 (PDT) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0121.outbound.protection.outlook.com [104.47.38.121]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A24F8127B31 for ; Wed, 14 Jun 2017 14:01:11 -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=FQpcRzvjO5QTk/+UD0NUHnXnTDu1FVYq4lPrcYkHo2s=; b=nxzgbJtoETPn/RIWjfSLu9cert2KFmtoTQJODoclgnsRfdimz04z9og6iBqs4nMghU/Y8hgtuT/RwY9Egr52LgW9l75eWuU92CXAtRWgiu3z79YaTj8GZru5M9D4BttNPqgJWRpm9x5YxrwWPltUGHBCD4do9CCJEoSUshWzuMw= Received: from DM2PR21MB0091.namprd21.prod.outlook.com (10.161.141.14) by DM2PR21MB0073.namprd21.prod.outlook.com (10.161.140.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1199.3; Wed, 14 Jun 2017 21:01:08 +0000 Received: from DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2d6d:96d3:f164:d70f]) by DM2PR21MB0091.namprd21.prod.outlook.com ([fe80::2d6d:96d3:f164:d70f%15]) with mapi id 15.01.1199.000; Wed, 14 Jun 2017 21:01:08 +0000 From: Andrei Popov To: David Benjamin , =?utf-8?B?UGV0ciDFoHBhxI1law==?= , "tls@ietf.org" Thread-Topic: [TLS] Separate APIs for 0-RTT Thread-Index: AQHS5B82VxUJW2RS/kmCucGOID4L7aIit00AgAABTICAAD1wkIAABhGAgAAS9ICAAAKWgIAABRGAgAAA6oCAAAfUAIAAA2CAgAACI1CAACGTAIAAnPmAgADkkgCAAA/9kA== Date: Wed, 14 Jun 2017 21:01:08 +0000 Message-ID: References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: chromium.org; dkim=none (message not signed) header.d=none; chromium.org; dmarc=none action=none header.from=microsoft.com; x-originating-ip: [2001:4898:80e8:b::4ca] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM2PR21MB0073; 7:XN9d4yigE0Ylv9lAvLiGun5U19krrQhfX7c8yQl5oLuIQB8kmDZ007oWhoK+a5wxFwYKV2HsA985a+cFuUAIsKPDruFXApVcJxYc85zlp24hOmaXvOC2NCLIc4jhgqEAaJV76+b3nZZc4aMmsMlSPI1nMICWCvAd1QTJXL7UVHXc9id+9QbL+NzodufaJ61ILW4KIAWg1uBxLLzme9DkrUZj9Kr42IJyHRzCvAVaredQqSw1hvYLSEthrSTwo1aODPK5a51I13zmaxcQg/lsnqpuPq37Ua5jbZDN327NHWUds0ABXgXK9KY3an4+9h6ktCWxO5ODBNTFiDO9K+K6ujj90C3/sVaahHUvCtV3CL2Oq+WLbF+VJrYc+zRKkpqUjltFXIVQO5abVW60g4b48XDTof9+DN5dS821xrTyH1ozvgAt0znOXRufnyAl8nryUyHjkUq8uQVERjX7fYZHdvnOBsogwgi7/dQhWy8UciR1LmNdumLxE8VUY14niBIh5qP0l6w2nn+jU/ZhrYt52EmKWofcdYa9gmpmW/eZnObvFTvJDoS0WwxpjQRUxkpIE7HXhOfk9pz7a7I3EE2aV//zt5X4WIGhJVGRzOw8tZD95NnKc8w9DV490M1bmQ/eMTnTi/ga6hAHUqcpdIjRUd5QD851qddsp5VmFwF0/3yveefDNUtjklR7JZOQ7MAmL5ZXiRmhW2DV7L9W3xTlCpv/xM1Ej4faWGGdWCqYtllyPjgGbwmSaSNzx9Wg1yhrpW02bYjLlHeD89SIj5sKCJRzQi/hcDHSzsm+tRy+15/GdzeDj1O06Fo+Rdt/DZMp x-ms-office365-filtering-correlation-id: 2e09f391-645c-4638-5fdd-08d4b3687b09 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(48565401081)(201703131423075)(201703031133081); SRVR:DM2PR21MB0073; x-ms-traffictypediagnostic: DM2PR21MB0073: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(61425038)(6040450)(601004)(2401047)(8121501046)(5005006)(10201501046)(100000703101)(100105400095)(3002001)(93006095)(93001095)(6055026)(61426038)(61427038)(6041248)(20161123564025)(20161123560025)(20161123558100)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123555025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM2PR21MB0073; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM2PR21MB0073; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(39860400002)(39450400003)(39400400002)(39840400002)(39410400002)(72206003)(7736002)(10290500003)(25786009)(8936002)(50986999)(86362001)(478600001)(74316002)(14454004)(6306002)(53936002)(6246003)(2950100002)(54896002)(9686003)(8990500004)(38730400002)(6506006)(76176999)(5660300001)(54356999)(6436002)(55016002)(99286003)(93886004)(10090500001)(33656002)(5005710100001)(2906002)(3660700001)(229853002)(790700001)(7696004)(3280700002)(189998001)(2900100001)(6116002)(102836003)(5250100002)(8676002)(81166006)(2501003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR21MB0073; H:DM2PR21MB0091.namprd21.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR21MB009176844759F65141E1D6EA8CC30DM2PR21MB0091namp_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.com X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2017 21:01:08.6233 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR21MB0073 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 21:01:15 -0000 --_000_DM2PR21MB009176844759F65141E1D6EA8CC30DM2PR21MB0091namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 ICAqICAgV2hhdCBpZiB0aGUgc2VydmVyIHJlY2VpdmVzIGRhdGEgd2l0aCB0aGUgMC1SVFQgYm91 bmRhcnkgc3Bhbm5pbmcgYW4gSFRUUC8yIGZyYW1lPyBJcyB0aGF0IGEgMC1SVFQgcmVxdWVzdD8g MS1SVFQ/IEludmFsaWQ/DQpJdCBhcHBlYXJzIHNhZmUgdG8gdHJlYXQgc3VjaCBkYXRhIGFzIDAt UlRUOyBvbmx5IHRoZSBhcHBsaWNhdGlvbiBjYW4gbWFrZSB0aGlzIGNhbGwsIGFuZCBpdCBuZWVk cyBpbmZvIGZyb20gdGhlIFRMUyBzdGFjayB0byBtYWtlIHRoaXMgY2FsbC4NCg0KDQogICogICBX ZSBjb3VsZCBzYXkgdGhhdCB0aGUgYXBwbGljYXRpb24gcHJvZmlsZSBzaG91bGQgbW9kaWZ5IHRo ZSBwcm90b2NvbCB0byByZWplY3Qgc3VjaCBjYXNlcy4gTm93LCB3ZeKAmXJlIHRha2luZyBvbiBj b21wbGV4aXR5IGluIGV2ZXJ5IHByb3RvY29sIHNwZWNpZmljYXRpb24gYW5kIHBhcnNlci4NCkl0 IHdvdWxkIG9mIGNvdXJzZSBiZSBwcmVmZXJhYmxlIChzb21lIHdvdWxkIGFyZ3VlLCBuZWNlc3Nh cnkpIHRvIHNlY3VyZSAwLVJUVCBhcHBsaWNhdGlvbl9kYXRhIGF0IHRoZSBUTFMgbGF5ZXIsIGJ1 dCBzbyBmYXIgd2XigJl2ZSBmYWlsZWQgdG8gY29tZSB1cCB3aXRoIGEgd2F5IHRvIGRvIHNvLg0K DQoNCiAgKiAgIE91ciBwcm9ibGVtIGlzIGEgc2VydmVyIHdpc2hlcyBub3QgdG8gcHJvY2VzcyBz b21lIEhUVFAgcmVxdWVzdHMgKG9yIG90aGVyIHByb3RvY29sIHVuaXRzKSBhdCAwLVJUVCBhbmQg bmVlZHMgdG8gZGV0ZWN0IHRoaXMgY2FzZS4gU28gY2hlY2sgYSBib29sZWFuIHNpZ25hbCBmb3Ig d2hldGhlciB0aGUgY29ubmVjdGlvbiBoYXMgY3VycmVudGx5IHBhc3NlZCB0aGUgMS1SVFQgcG9p bnQgYmVmb3JlIGFueSB1bnNhZmUgcHJvY2Vzc2luZy4NCkkgdGhpbmsgdGhpcyB3b3VsZCBiZSBh IHZhbGlkIGltcGxlbWVudGF0aW9uIG9mICMzLiBUaGVyZSBtYXkgYmUgb3RoZXIgaW1wbGVtZW50 YXRpb24gb3B0aW9ucyB0aGF0IG1ha2UgbW9yZSBzZW5zZSBmb3IgYSBkaWZmZXJlbnQgVExTIEFQ SSBvciBhIGRpZmZlcmVudCBhcHBsaWNhdGlvbiBwcm90b2NvbCwgc28gSeKAmWQgcmF0aGVyIG5v dCBwdXQgYSBzcGVjaWZpYyBpbXBsZW1lbnRhdGlvbiBvcHRpb24gaW4gdGhlIFJGQy4NCg0KQ2hl ZXJzLA0KDQpBbmRyZWkNCg== --_000_DM2PR21MB009176844759F65141E1D6EA8CC30DM2PR21MB0091namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZp c2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5 Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvTGlz dFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgNCgl7 bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdodDow aW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWww DQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixz YW5zLXNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFs LXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRv d3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjg5MDExMjgxMTsNCgltc28tbGlzdC10eXBl Omh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTIwNDczMzY4NTYgNDc1OTc3NDAgNjc2 OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2 OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZlbC1zdGFydC1hdDozOw0K CW1zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvg5g7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7DQoJbXNvLWZh cmVhc3QtZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglm b250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNA0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGww OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZlbDkN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0K CXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDow aW47bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzEiPldoYXQgaWYgdGhlIHNlcnZlciByZWNlaXZlcyBk YXRhIHdpdGggdGhlIDAtUlRUIGJvdW5kYXJ5IHNwYW5uaW5nIGFuIEhUVFAvMiBmcmFtZT8gSXMg dGhhdCBhIDAtUlRUIHJlcXVlc3Q/IDEtUlRUPyBJbnZhbGlkPzxvOnA+PC9vOnA+PC9saT48L3Vs Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SXQgYXBwZWFycyBzYWZlIHRvIHRyZWF0IHN1Y2ggZGF0 YSBhcyAwLVJUVDsgb25seSB0aGUgYXBwbGljYXRpb24gY2FuIG1ha2UgdGhpcyBjYWxsLCBhbmQg aXQgbmVlZHMgaW5mbyBmcm9tIHRoZSBUTFMgc3RhY2sgdG8gbWFrZSB0aGlzIGNhbGwuPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjx1 bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGluO21zby1saXN0OmwwIGxldmVsMSBsZm8x Ij5XZSBjb3VsZCBzYXkgdGhhdCB0aGUgYXBwbGljYXRpb24gcHJvZmlsZSBzaG91bGQgbW9kaWZ5 IHRoZSBwcm90b2NvbCB0byByZWplY3Qgc3VjaCBjYXNlcy4gTm93LCB3ZeKAmXJlIHRha2luZyBv biBjb21wbGV4aXR5IGluIGV2ZXJ5IHByb3RvY29sIHNwZWNpZmljYXRpb24gYW5kIHBhcnNlci48 bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHdvdWxkIG9mIGNv dXJzZSBiZSBwcmVmZXJhYmxlIChzb21lIHdvdWxkIGFyZ3VlLCBuZWNlc3NhcnkpIHRvIHNlY3Vy ZSAwLVJUVCBhcHBsaWNhdGlvbl9kYXRhIGF0IHRoZSBUTFMgbGF5ZXIsIGJ1dCBzbyBmYXIgd2Xi gJl2ZSBmYWlsZWQgdG8gY29tZSB1cCB3aXRoIGEgd2F5IHRvIGRvIHNvLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dWwgc3R5bGU9 Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBpbjttc28tbGlzdDpsMCBsZXZlbDEgbGZvMSI+T3VyIHBy b2JsZW0gaXMgYSBzZXJ2ZXIgd2lzaGVzIG5vdCB0byBwcm9jZXNzIHNvbWUgSFRUUCByZXF1ZXN0 cyAob3Igb3RoZXIgcHJvdG9jb2wgdW5pdHMpIGF0IDAtUlRUIGFuZCBuZWVkcyB0byBkZXRlY3Qg dGhpcyBjYXNlLiBTbyBjaGVjayBhIGJvb2xlYW4gc2lnbmFsIGZvciB3aGV0aGVyIHRoZSBjb25u ZWN0aW9uDQogaGFzIGN1cnJlbnRseSBwYXNzZWQgdGhlIDEtUlRUIHBvaW50IGJlZm9yZSBhbnkg dW5zYWZlIHByb2Nlc3NpbmcuIDxvOnA+PC9vOnA+PC9saT48L3VsPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+SSB0aGluayB0aGlzIHdvdWxkIGJlIGEgdmFsaWQgaW1wbGVtZW50YXRpb24gb2YgIzMu IFRoZXJlIG1heSBiZSBvdGhlciBpbXBsZW1lbnRhdGlvbiBvcHRpb25zIHRoYXQgbWFrZSBtb3Jl IHNlbnNlIGZvciBhIGRpZmZlcmVudCBUTFMgQVBJIG9yIGEgZGlmZmVyZW50IGFwcGxpY2F0aW9u IHByb3RvY29sLCBzbyBJ4oCZZCByYXRoZXIgbm90IHB1dCBhIHNwZWNpZmljIGltcGxlbWVudGF0 aW9uIG9wdGlvbiBpbiB0aGUNCiBSRkMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycyw8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kcmVpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_DM2PR21MB009176844759F65141E1D6EA8CC30DM2PR21MB0091namp_-- From nobody Wed Jun 14 14:38:52 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1544312922E for ; Wed, 14 Jun 2017 14:38:51 -0700 (PDT) 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=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 4wX_zrYvbGOv for ; Wed, 14 Jun 2017 14:38:49 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 4A5B91243F3 for ; Wed, 14 Jun 2017 14:38:49 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5ELRbqX027861; Wed, 14 Jun 2017 22:38:44 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type; s=jan2016.eng; bh=tHqZWC52PbPBPnHDCBK/IQPQfIS93wUBx1vjwqe2O5o=; b=CSi7i8R1/ZGIv6sXlRSdmgo2WspGmkIGEZlluXJOw9ZzmwogBtLVz1nHQlYYUEfY7tty vf5wn4SF2LpESnDgLaKS6YLVyqV60nQpk2i2QYHzKId/9QCbceSOF0OwanmBvFSnCa9p p77AwvgFNqDBshinGdnKqhVeXNaO+ywyz6TTDfOPwb1FAZFwttT/iB2RXghua257EHy5 Wn4q4EuQU12BJvFw2ahU5/m3yjo++TnwDjUGmzFE/a+6HOa3uULe2TAzODZA0Sd2AO1g zl60wZEfPbUByygj/o8TC4QKmd4MMeiKWoZHL0Apkzl/e9x3hgYZepGaE84wPs+8eoYW Aw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2b2ndvfneb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 14 Jun 2017 22:38:44 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5ELaNV5000885; Wed, 14 Jun 2017 17:38:42 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b0c3vufbb-1; Wed, 14 Jun 2017 17:38:42 -0400 Received: from bos-mpeve.kendall.corp.akamai.com (unknown [172.19.33.3]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 5B5D880052; Wed, 14 Jun 2017 15:38:42 -0600 (MDT) From: Brian Sniffen To: Steven Valdez , Eric Rescorla , "Salz\, Rich" Cc: "tls\@ietf.org" In-Reply-To: References: <0a4f3f85fa80423ea72d3eec4c7710aa@usma1ex-dag1mb1.msg.corp.akamai.com> Date: Wed, 14 Jun 2017 17:38:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-14_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1706140356 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-14_05:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706140354 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 21:38:51 -0000 Steven Valdez writes: > Confirming that BoringSSL is using a single API for early/regular data, > since we ran into issues/complications with our implementation of dual APIs > with our use cases. I predict that those are exactly the places you're going to have later security incidents. In particular, the use case of fusing the early and regular data into a single stream is going to lead to problems like Triple Handshake. The history of APIs where some bits have different secrecy, freshness, or authentication than the rest says they all end up with bugs related to user assumptions that blur away the difference. -Brian -- Brian Sniffen /(* Akamai - Faster Forward From nobody Wed Jun 14 15:24:10 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F584127077 for ; Wed, 14 Jun 2017 15:24:09 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 xNLFNUBhrZWJ for ; Wed, 14 Jun 2017 15:24:07 -0700 (PDT) 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 EE17F120724 for ; Wed, 14 Jun 2017 15:24:06 -0700 (PDT) Received: by mail-pg0-x22e.google.com with SMTP id a70so6027292pge.3 for ; Wed, 14 Jun 2017 15:24:06 -0700 (PDT) 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=CL3t9OdUYFx0grBYdW7G1AaYpqMoSZX6zn6pqO+rwt8=; b=TVFgNa7tszTjw1ILUt3tt9C45EXS5GjDyw3LUfBIZrkHYKWZSGDQ5SYRK5rDLw5uUi 8PL35VyzVELwUu/2U90UAU3vROhgWWqyI6Do7AEDvJWnuX/sMFXqU3hC3rfr/aJsrUIY tOMbe5eyflKuOzbxNGTqza/cHPhJXw2Q8sO34= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=CL3t9OdUYFx0grBYdW7G1AaYpqMoSZX6zn6pqO+rwt8=; b=kOBlVW6PP8fpxbIvYugXzAiqL50GEL5B/o6zKdji1rUbpsJE65kxJnlT99TP6WQxln atfHqQuWgUZ8H2VGFSxGv3H9u4tIh4lE0rg2Rj8JZaahyUVzocUHEzd5fwNUedvs2iqg +C6G3Gl5zsi+Bd/BlXU8ty3x2bwgo4uzf80hlKzbQxhUOas/3c4EoEQGeIxI2tQm2Im+ kNBqVl14b4R+FdJdaoGhYEo5TvXg/TfcFqKrqI0BvaoDRTAVb5eOqOjon55SPGWIXk4N bQQhkq/PcORqhrIdh/wqNTASy949Xo8G7n08e6Y8dWqTCPFe1zEZpSOFL7zFMTNFQz/L XPdA== X-Gm-Message-State: AKS2vOyba6CCW8tKfhaTPqGOLfszkDCUqnzdH0WtspzQZ/spQUCRU0GF FbSJINzKVtLdALUX9HojBUJa2KmpZAICe8k= X-Received: by 10.84.128.33 with SMTP id 30mr2559100pla.38.1497479046344; Wed, 14 Jun 2017 15:24:06 -0700 (PDT) MIME-Version: 1.0 References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: David Benjamin Date: Wed, 14 Jun 2017 22:23:54 +0000 Message-ID: To: Andrei Popov , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c11e98e9e0b160551f302fa" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 22:24:09 -0000 --94eb2c11e98e9e0b160551f302fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 14, 2017 at 5:01 PM Andrei Popov wrote: > > - What if the server receives data with the 0-RTT boundary spanning an > HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid? > > It appears safe to treat such data as 0-RTT; only the application can mak= e > this call, and it needs info from the TLS stack to make this call. > I actually would suggest it being 1-RTT. Or rather that a processing-time check would count it as 1-RTT. Though I think I don't see anything particularly wrong with it being 0-RTT either? *shrug* > > > > - We could say that the application profile should modify the protocol > to reject such cases. Now, we=E2=80=99re taking on complexity in every= protocol > specification and parser. > > It would of course be preferable (some would argue, necessary) to secure > 0-RTT application_data at the TLS layer, but so far we=E2=80=99ve failed = to come up > with a way to do so. > > > > - Our problem is a server wishes not to process some HTTP requests (or > other protocol units) at 0-RTT and needs to detect this case. So check= a > boolean signal for whether the connection has currently passed the 1-R= TT > point before any unsafe processing. > > I think this would be a valid implementation of #3. There may be other > implementation options that make more sense for a different TLS API or a > different application protocol, so I=E2=80=99d rather not put a specific > implementation option in the RFC. > Sure, if that is the interpretation of #3, that works fine for me. My objection is to trying to pass along a hard separation between the two chunks of data, to the point that the sender actually cares about some data getting sent *before* the boundary. Caring about some data being sent after the boundary is very reasonable and natural. POSTs, perhaps. Before is complex because you must synchronize and defer the boundary. The trouble is a before constraint gets implied by lots of stuff. Specifically, I would propose a looser phrasing for #3: When accepting 0-RTT as a server, a TLS implementation SHOULD/MUST provide a way for the application to determine if the client Finished has been processed. That is, it is not the identity of the bytes that matters much. It's whether the connection has been confirmed when you perform an unsafe action. I believe this still satisfies the properties we want, but without breaking standard interfaces. Very near the TLS stack, at the point where the record boundary abstraction starts leaking (it's common to only give you back a single record on read), either API is equally easy to provide. The looser phrasing is needed for composition once you start going up a layer or to. David > --94eb2c11e98e9e0b160551f302fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 14= , 2017 at 5:01 PM Andrei Popov <Andrei.Popov@microsoft.com> wrote:
=
  • What if the server receives data with the 0-RTT bo= undary spanning an HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid?

It appears safe to treat such data as 0-RTT; only the application = can make this call, and it needs info from the TLS stack to make this call.=


I actually would suggest it being 1-RTT. Or rather = that a processing-time check would count it as 1-RTT. Though I think I don&= #39;t see anything particularly wrong with it being 0-RTT either? *shrug*
=C2=A0

=C2=A0

  • We could say that the application profile should m= odify the protocol to reject such cases. Now, we=E2=80=99re taking on compl= exity in every protocol specification and parser.

It would of course be preferable (some would argue, necessary) to = secure 0-RTT application_data at the TLS layer, but so far we=E2=80=99ve fa= iled to come up with a way to do so.

=C2=A0

  • Our problem is a server wishes not to process some= HTTP requests (or other protocol units) at 0-RTT and needs to detect this = case. So check a boolean signal for whether the connection has currently passed the 1-RTT point before any unsafe processing. =

I think this would be a valid implementation of #3. There may be o= ther implementation options that make more sense for a different TLS API or= a different application protocol, so I=E2=80=99d rather not put a specific= implementation option in the RFC.


Sure, if that is the interpretation of #= 3, that works fine for me. My objection is to trying to pass along a hard s= eparation between the two chunks of data, to the point that the sender actu= ally cares about some data getting sent *before* the boundary. Caring about= some data being sent after the boundary is very reasonable and natural. PO= STs, perhaps. Before is complex because you must synchronize and defer the = boundary. The trouble is a before constraint gets implied by lots of stuff.=

Specifically, I would propose a looser phrasing f= or #3:

When accepting 0-RTT as a server, a TLS imp= lementation SHOULD/MUST provide a way for the application to determine if t= he client Finished has been processed.

That is= , it is not the identity of the bytes that matters much. It's whether t= he connection has been confirmed when you perform an unsafe action. I belie= ve this still satisfies the properties we want, but without breaking standa= rd interfaces. Very near the TLS stack, at the point where the record bound= ary abstraction starts leaking (it's common to only give you back a sin= gle record on read), either API is equally easy to provide. The looser phra= sing is needed for composition once you start going up a layer or to.
=

David

<= /div>
--94eb2c11e98e9e0b160551f302fa-- From nobody Wed Jun 14 15:47:45 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428361294E7 for ; Wed, 14 Jun 2017 15:47:44 -0700 (PDT) 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=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 C4Gh9QNeptyU for ; Wed, 14 Jun 2017 15:47:42 -0700 (PDT) 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 C1CAB1293E8 for ; Wed, 14 Jun 2017 15:47:42 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id t7so4526665yba.3 for ; Wed, 14 Jun 2017 15:47:42 -0700 (PDT) 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=oQ96rCopnmopmhYvHWC6z+0vRD6uMC47JJpM+M36b7I=; b=ERmHzirrSD/TNp98gL6WX+5EGaQDg6Wfl7vwcocB611WnUjJn2xyf0C/VXbMZLdcNt 1sscl2bzsopcQ8vO7BGDpWhC9+TLM8dJiFtywks5De+7vxKOksFb7BriAl4lh5Qgc5BU HCKifcG6hNeSbRZG1ZCOtsaikdslfjSSbZVjNa18ptn+alci0ojw7lZEUOJ7hsxsjZVP ND+a8GB/1IQ8gFE+GvTpIMgTt7vn0zqLV0tI+KM1Irm4pp4z5LwAo1eKeOJbm5RN6G77 wyodMRcm6VzUCknefSnLmRqRF4OiK8zzsdXIpjqs8rva+Vi2GozlsrYubTJBFi7OMh1J IYNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=oQ96rCopnmopmhYvHWC6z+0vRD6uMC47JJpM+M36b7I=; b=NkYOWjPqnGhFqdxeJ1YNYUQXqgVSxuLU4q5MQdaWhs61Yln2/WpVnhj1K0yC3qP1Dl F9a86rP5A2xezRHza9As78rBjVv+YbpPex2VtDcVrJ/IWTIWwhfTypEpN87gR0nRH4tq VTW2BE9H3IirGJOi2e3F2HlgR0siKqfVbqL61KakwrW07KxI6zTOhtsa2Q7+sU5EjePO 6j+kva44h8ew0GkyuSAIaCza8Xromgh4S8bCaS/dKG8U4qgYXW+2EPxPQYmCCTsO82lG oZseU5brytVdDv5OgHOPmUwrh+xeDroPv6m1j4u9s2jTlKO4QhBjHk9uTcev4NEWi9Ec GxXQ== X-Gm-Message-State: AKS2vOxbqUxc8/AoMJE8Clr4sIKe6Psx3/wvTmqFtGoF94aEYrIchMkp 04AJ6CXsdAxymUCipjL/7YpV6PORTS8X X-Received: by 10.37.50.5 with SMTP id y5mr2018945yby.204.1497480461983; Wed, 14 Jun 2017 15:47:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.93.70 with HTTP; Wed, 14 Jun 2017 15:47:41 -0700 (PDT) In-Reply-To: References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Wed, 14 Jun 2017 15:47:41 -0700 Message-ID: To: David Benjamin Cc: Andrei Popov , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1146df52febcdc0551f3567b" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 22:47:44 -0000 --001a1146df52febcdc0551f3567b Content-Type: text/plain; charset="UTF-8" On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin wrote: > That is, it is not the identity of the bytes that matters much. It's > whether the connection has been confirmed when you perform an unsafe > action. I believe this still satisfies the properties we want, but without > breaking standard interfaces. Very near the TLS stack, at the point where > the record boundary abstraction starts leaking (it's common to only give > you back a single record on read), either API is equally easy to provide. > The looser phrasing is needed for composition once you start going up a > layer or to. > Suppose a request, or a frame, spans two different client certificate authentication contexts (or unauthenticated, and authenticated); how is that handled today? or is it just forbidden? -- Colm --001a1146df52febcdc0551f3567b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin <<= a href=3D"mailto:davidben@chromium.org" target=3D"_blank">davidben@chromium= .org> wrote:
That is, it= is not the identity of the bytes that matters much. It's whether the c= onnection has been confirmed when you perform an unsafe action. I believe t= his still satisfies the properties we want, but without breaking standard i= nterfaces. Very near the TLS stack, at the point where the record boundary = abstraction starts leaking (it's common to only give you back a single = record on read), either API is equally easy to provide. The looser phrasing= is needed for composition once you start going up a layer or to.
=

Suppose a request, or a= frame, spans two different client certificate authentication contexts (or = unauthenticated, and authenticated); how is that handled today? or is it ju= st forbidden?

--
Colm
--001a1146df52febcdc0551f3567b-- From nobody Wed Jun 14 16:31:35 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 979521270FC for ; Wed, 14 Jun 2017 16:31:33 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 5Us_w2EurLTF for ; Wed, 14 Jun 2017 16:31:31 -0700 (PDT) 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 316241200CF for ; Wed, 14 Jun 2017 16:31:31 -0700 (PDT) Received: by mail-pf0-x236.google.com with SMTP id x63so7426777pff.3 for ; Wed, 14 Jun 2017 16:31:31 -0700 (PDT) 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=5yx8/6GFKiSSM9wFO3n2uyJGJnzzpRKrIGWzSDGTBYE=; b=H0BWSF+4cQu84Uq2jYfZmrQdTFFAFoLJZZnVyKnU2wB1RZXxsg7QU5m6rb0vWR8Ig4 yAQMwLkP8QxmomKo/cNRJbpzzj3Q8bvXYHBfNnaJufy+PdN3BP/5tQQVSS4EobyTu0jy QxCVQxBRKkPvjrapy6HL1r/E1hGmD3neqe5I0= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5yx8/6GFKiSSM9wFO3n2uyJGJnzzpRKrIGWzSDGTBYE=; b=JfBVM+QoI8qPf7HYWinO5VZzWc1Wla33UP+o86GHV+qPBwnO/tHHatM9ca0pr3cm9v bDutiG3y4HrsGkZfO/Rtgf5Rs2xT4fU5LhyvCzNTgQdpaAChMngo/Gz9SmUufApKlpFn iKcl/TNlrd3p9k+e7jFP0hsEwaeeU77GVLUtuxHr1bSvrVKr5ig2tlI31xFxwCJIdNYS G8qcUlV74OSx2wPJ+Td1WPi4hxWORn1S8eQcypyejZtvPXqSIbCbQL4bMgDAF+aeImPr br8Em4NfB+XE4Yuq8214JlvMUMM2gb1Pz9fjOUFsAus/4udp1MfbQf0qmvLfTTJQUaNb OHQA== X-Gm-Message-State: AKS2vOzokVxAbY1PChQbq7WALvj6u8ACx9ZNu0poXjrGMtqFqwAi/gHO udTC1iIF0g31VtIKERavHceNizp7T3H9 X-Received: by 10.84.136.129 with SMTP id 1mr2682586pll.213.1497483090667; Wed, 14 Jun 2017 16:31:30 -0700 (PDT) MIME-Version: 1.0 References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: David Benjamin Date: Wed, 14 Jun 2017 23:31:19 +0000 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Andrei Popov , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c1196aaad8c7f0551f3f371" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 23:31:34 -0000 --94eb2c1196aaad8c7f0551f3f371 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 14, 2017 at 6:47 PM Colm MacC=C3=A1rthaigh = wrote: > On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin > wrote: > >> That is, it is not the identity of the bytes that matters much. It's >> whether the connection has been confirmed when you perform an unsafe >> action. I believe this still satisfies the properties we want, but witho= ut >> breaking standard interfaces. Very near the TLS stack, at the point wher= e >> the record boundary abstraction starts leaking (it's common to only give >> you back a single record on read), either API is equally easy to provide= . >> The looser phrasing is needed for composition once you start going up a >> layer or to. >> > > Suppose a request, or a frame, spans two different client certificate > authentication contexts (or unauthenticated, and authenticated); how is > that handled today? or is it just forbidden? > In TLS 1.2, that would require renegotiation, which is not allowed in HTTP/2. Our client and server implementations enforce this, for this and other reasons. http://httpwg.org/specs/rfc7540.html#rfc.section.9.2.1 Sadly, in Chrome as an HTTP/1.1 client, we are stuck with supporting this mess, so we allow it at HTTP/1.1, but we will only accept client certificate requests between request and response and further forbid all handshake/application interleave. HTTP/1.1 without pipelining is just barely simple enough that one can get away with all this. (In all other cases, BoringSSL does not support renegotiation at all.) The mess around trying to make byte boundaries semantically meaningful is why I'd previously advocated leaving TLS 1.3 post-handshake auth to the application profile, and why I advocated that it never be allowed in HTTP/2. HTTP/2 should use something at its layer, possibly leaning on exported authenticators. We have no plans to implement TLS 1.3 post-handshake auth in BoringSSL, but if we were ever to implement it, it would likely be under the same constraints as renegotiation (off by default, client-only, HTTP/1.1-only, and only at that one point in the protocol with no interleave). I assume what you're getting at here is that my 0-RTT and post-handshake auth preferences are the opposite? :-) That's true. In the post-handshake auth case, making the boundary insignificant to the higher-level protocol isn't really feasible. Conversely, forbidding 0-RTT with HTTP/2 would be rather unfortunate. But it seems the tight synchronization is not needed here, so we don't need to go that route. --94eb2c1196aaad8c7f0551f3f371 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 14= , 2017 at 6:47 PM Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin <davidben@chromium.or= g> wrote:
=
That is, it is not the id= entity of the bytes that matters much. It's whether the connection has = been confirmed when you perform an unsafe action. I believe this still sati= sfies the properties we want, but without breaking standard interfaces. Ver= y near the TLS stack, at the point where the record boundary abstraction st= arts leaking (it's common to only give you back a single record on read= ), either API is equally easy to provide. The looser phrasing is needed for= composition once you start going up a layer or to.
<= /div>

Suppose a request, or a= frame, spans two different client certificate authentication contexts (or = unauthenticated, and authenticated); how is that handled today? or is it ju= st forbidden?

In TL= S 1.2, that would require renegotiation, which is not allowed in HTTP/2. Ou= r client and server implementations enforce this, for this and other reason= s.

Sadly, in Chrome as an HTTP/1.1 client, we are stuck with= supporting this mess, so we allow it at HTTP/1.1, but we will only accept = client certificate requests between request and response and further forbid= all handshake/application interleave. HTTP/1.1 without pipelining is just = barely simple enough that one can get away with all this. (In all other cas= es, BoringSSL does not support renegotiation at all.)

<= div>The mess around trying to make byte boundaries semantically meaningful = is why I'd previously advocated leaving TLS 1.3 post-handshake auth to = the application profile, and why I advocated that it never be allowed in HT= TP/2. HTTP/2 should use something at its layer, possibly leaning on exporte= d authenticators. We have no plans to implement TLS 1.3 post-handshake auth= in BoringSSL, but if we were ever to implement it, it would likely be unde= r the same constraints as renegotiation (off by default, client-only, HTTP/= 1.1-only, and only at that one point in the protocol with no interleave).

I assume what you're getting at here is that my= 0-RTT and post-handshake auth preferences are the opposite? :-) That's= true. In the post-handshake auth case, making the boundary insignificant t= o the higher-level protocol isn't really feasible. Conversely, forbiddi= ng 0-RTT with HTTP/2 would be rather unfortunate. But it seems the tight sy= nchronization is not needed here, so we don't need to go that route.
--94eb2c1196aaad8c7f0551f3f371-- From nobody Wed Jun 14 16:38:29 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5BB0129420 for ; Wed, 14 Jun 2017 16:38:28 -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, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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=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 0l2ku6d1UREm for ; Wed, 14 Jun 2017 16:38:26 -0700 (PDT) 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 2487212871F for ; Wed, 14 Jun 2017 16:38:26 -0700 (PDT) Received: by mail-pg0-x22f.google.com with SMTP id a70so6677466pge.3 for ; Wed, 14 Jun 2017 16:38:26 -0700 (PDT) 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=W/ch4x7WpUMwdoeLYCJggf2iI1baIlWb5m9pkfDxxL4=; b=OB82NjA3oQskMeVi/gUbU6PBTGPryAcoDbuhTtDcYIyuaP/Mz+/m1/Efe+m59dnJU5 4STmN7XiwsTbWZpC8Yk2TKGCeRrqPRe6Qv/4dy6tRoq9N6RMp77dsTgxQF6uDYLdtrbM Nt9poYjva5Jx7cORvwdOsx3KSbG8o/zIVAyKc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=W/ch4x7WpUMwdoeLYCJggf2iI1baIlWb5m9pkfDxxL4=; b=PoqvcL3RmnoP+NBSyQ3kms8q2DQZTmLAOEJvSx1lkmf4yVegHJOJcIGdKk/F2NZbZE fYEsFYH5nmTzPFw6jIK9uWbd831Y6VPM4LcndVA+Jq5mxJ4GT7qqtG7i4LjNu/fQkEQ3 G4umzh/jOjIG3A8mMBk7wh68Zh67ScIGHtkeOKJa9vZnwdoqKgLNq3nRT/t/tIl1knNt e5j/IoqsZHJAHMnF65xv0De/hTi4x9IzQdSNIDy776rY87L8ctXo6yM3R00fb9FQkIsp 1P6G3nWzsLYbMJoyLuHlSi7Er5wlkTsDJZPVkQxDrIgrekhHp1DYKShTZykXCeRlT/7s IcIg== X-Gm-Message-State: AKS2vOzMs00hwK/adDutPGR13OcXeAzqHUb6S7WQ4CoCYOU/Ev9CFyzl cT5acn4aqyTmNneq3mIqT4GLBpd3Wgud X-Received: by 10.98.89.155 with SMTP id k27mr2300953pfj.70.1497483505641; Wed, 14 Jun 2017 16:38:25 -0700 (PDT) MIME-Version: 1.0 References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> In-Reply-To: From: David Benjamin Date: Wed, 14 Jun 2017 23:38:15 +0000 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Andrei Popov , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1149229e698a200551f40c1e" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 14 Jun 2017 23:38:29 -0000 --001a1149229e698a200551f40c1e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jun 14, 2017 at 7:31 PM David Benjamin wrote: > On Wed, Jun 14, 2017 at 6:47 PM Colm MacC=C3=A1rthaigh > wrote: > >> On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin >> wrote: >> >>> That is, it is not the identity of the bytes that matters much. It's >>> whether the connection has been confirmed when you perform an unsafe >>> action. I believe this still satisfies the properties we want, but with= out >>> breaking standard interfaces. Very near the TLS stack, at the point whe= re >>> the record boundary abstraction starts leaking (it's common to only giv= e >>> you back a single record on read), either API is equally easy to provid= e. >>> The looser phrasing is needed for composition once you start going up a >>> layer or to. >>> >> >> Suppose a request, or a frame, spans two different client certificate >> authentication contexts (or unauthenticated, and authenticated); how is >> that handled today? or is it just forbidden? >> > > In TLS 1.2, that would require renegotiation, which is not allowed in > HTTP/2. Our client and server implementations enforce this, for this and > other reasons. > http://httpwg.org/specs/rfc7540.html#rfc.section.9.2.1 > > Sadly, in Chrome as an HTTP/1.1 client, we are stuck with supporting this > mess, so we allow it at HTTP/1.1, but we will only accept client > certificate requests between request and response and further forbid all > handshake/application interleave. HTTP/1.1 without pipelining is just > barely simple enough that one can get away with all this. (In all other > cases, BoringSSL does not support renegotiation at all.) > > The mess around trying to make byte boundaries semantically meaningful is > why I'd previously advocated leaving TLS 1.3 post-handshake auth to the > application profile, and why I advocated that it never be allowed in > HTTP/2. HTTP/2 should use something at its layer, possibly leaning on > exported authenticators. We have no plans to implement TLS 1.3 > post-handshake auth in BoringSSL, but if we were ever to implement it, it > would likely be under the same constraints as renegotiation (off by > default, client-only, HTTP/1.1-only, and only at that one point in the > protocol with no interleave). > > I assume what you're getting at here is that my 0-RTT and post-handshake > auth preferences are the opposite? :-) That's true. In the post-handshake > auth case, making the boundary insignificant to the higher-level protocol > isn't really feasible. Conversely, forbidding 0-RTT with HTTP/2 would be > rather unfortunate. But it seems the tight synchronization is not needed > here, so we don't need to go that route. > I should probably add the two scenarios aren't quite analogous. The 0-RTT boundary is a problem even in HTTP/1.1-like protocols because there is a send limit. If you're trying to fit the HTTP/1.1 request before the boundary, you can't stream it (request body?). The size needs to be known ahead of time. David --001a1149229e698a200551f40c1e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Jun 14= , 2017 at 7:31 PM David Benjamin <davidben@chromium.org> wrote:
On Wed, J= un 14, 2017 at 6:47 PM Colm MacC=C3=A1rthaigh <colm@allcosts.net> wrote:
On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin <davidben@chromium.org> wrote:
Th= at is, it is not the identity of the bytes that matters much. It's whet= her the connection has been confirmed when you perform an unsafe action. I = believe this still satisfies the properties we want, but without breaking s= tandard interfaces. Very near the TLS stack, at the point where the record = boundary abstraction starts leaking (it's common to only give you back = a single record on read), either API is equally easy to provide. The looser= phrasing is needed for composition once you start going up a layer or to.<= br>

<= div dir=3D"ltr">
= Suppose a request, or a frame, spans two different client certificate authe= ntication contexts (or unauthenticated, and authenticated); how is that han= dled today? or is it just forbidden?

I= n TLS 1.2, that would require renegotiation, which is not allowed in HTTP/2= . Our client and server implementations enforce this, for this and other re= asons.

Sadly, in Chrome as an HTTP/1.1 cli= ent, we are stuck with supporting this mess, so we allow it at HTTP/1.1, bu= t we will only accept client certificate requests between request and respo= nse and further forbid all handshake/application interleave. HTTP/1.1 witho= ut pipelining is just barely simple enough that one can get away with all t= his. (In all other cases, BoringSSL does not support renegotiation at all.)=

The mess around trying to make byte boundaries se= mantically meaningful is why I'd previously advocated leaving TLS 1.3 p= ost-handshake auth to the application profile, and why I advocated that it = never be allowed in HTTP/2. HTTP/2 should use something at its layer, possi= bly leaning on exported authenticators. We have no plans to implement TLS 1= .3 post-handshake auth in BoringSSL, but if we were ever to implement it, i= t would likely be under the same constraints as renegotiation (off by defau= lt, client-only, HTTP/1.1-only, and only at that one point in the protocol = with no interleave).

I assume what you're gett= ing at here is that my 0-RTT and post-handshake auth preferences are the op= posite? :-) That's true. In the post-handshake auth case, making the bo= undary insignificant to the higher-level protocol isn't really feasible= . Conversely, forbidding 0-RTT with HTTP/2 would be rather unfortunate. But= it seems the tight synchronization is not needed here, so we don't nee= d to go that route.

I sho= uld probably add the two scenarios aren't quite analogous. The 0-RTT bo= undary is a problem even in HTTP/1.1-like protocols because there is a send= limit. If you're trying to fit the HTTP/1.1 request before the boundar= y, you can't stream it (request body?). The size needs to be known ahea= d of time.

David
--001a1149229e698a200551f40c1e-- From nobody Wed Jun 14 18:28:37 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EE712941D for ; Wed, 14 Jun 2017 18:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 dnF82VqR8pYe for ; Wed, 14 Jun 2017 18:28:31 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 9F14A128D64 for ; Wed, 14 Jun 2017 18:28:31 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5F1RBOO031011; Thu, 15 Jun 2017 02:28:29 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=Yr9JaCNAdU6IswJJecYMefaL42nrCtMV6WPWWpqx0So=; b=SzMYlwt3pkDm/48UzNxlPqUfNBlcas2zPrv+NJc8/MsxNCd5rpCFBoS1816mfyRCH/jH 7lJEjtQ7z7JSHzReu0H2wboBKBniv8FrN6FkHB+SjDuc+ODl7cRlyGQ5QYqm8mrvzJhJ SJqTys8GwXypbu7F995bEKtw/3bAQ3BuGkmfWSAdMbLGEeSXzj1H858j/i5XQ5Z5SY9Y R5gYFIP1s9RSrr9w4JYtw7otxmxmrAsZGeKIhFEIm0ViIRi1jrqXxpr+QgKCM/yEhygP 7vlVTVrlOkBA4oY9VquPWOoLnALS5EVzZjK/aPAu83knfB77HSBRJfwWDP1rU1PB2HxP 1A== Received: from prod-mail-ppoint1 (a184-51-33-18.deploy.static.akamaitechnologies.com [184.51.33.18] (may be forged)) by m0050096.ppops.net-00190b01. with ESMTP id 2b2ndvggmh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 15 Jun 2017 02:28:28 +0100 Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5F1QKnk026372; Wed, 14 Jun 2017 21:28:27 -0400 Received: from prod-mail-relay10.akamai.com ([172.27.118.251]) by prod-mail-ppoint1.akamai.com with ESMTP id 2b0c3uquq7-1; Wed, 14 Jun 2017 21:28:27 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id CBD031FC71; Thu, 15 Jun 2017 01:28:26 +0000 (GMT) To: David Benjamin , tls@ietf.org References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk Message-ID: Date: Wed, 14 Jun 2017 20:28:26 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------D10E9368A23D8254F7E81EBC" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-15_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default 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-1703280000 definitions=main-1706150023 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-15_01:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706150024 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 15 Jun 2017 01:28:36 -0000 This is a multi-part message in MIME format. --------------D10E9368A23D8254F7E81EBC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/14/2017 02:55 PM, David Benjamin wrote: > On Wed, Jun 14, 2017 at 2:17 AM Petr Špaček > wrote: > > > > On 13.6.2017 22:55, Ilari Liusvaara wrote: > > On Tue, Jun 13, 2017 at 06:57:05PM +0000, Andrei Popov wrote: > >> Regarding RFC language, I think we could be more specific: > >> > >> > >> > >> 1. A TLS implementation SHOULD/MUST only send 0-RTT application > data if the application has explicitly opted in; > >> > >> 2. A TLS implementation SHOULD/MUST only accept 0-RTT > application data if the application has explicitly opted in; > >> > >> 3. When delivering 0-RTT application data to the application, a > TLS implementation SHOULD/MUST provide a way for the application > to distinguish it from the rest of the application data. > > > > First of these has to be MUST, or you get problems like I outlined > > earlier. > > > > And to implement checking for client only sending "safe" data, > you need > > the second and third. > > I support MUST for the three points above. > > > The third one is not practical as one moves up layers. Instead, I > believe we can get the same benefit with a simpler signal. > > TLS fundamentally is a transformation from a vaguely TCP-like > transport to another vaguely TCP-like transport. Consider TLS records: > TLS could have decided record boundaries were meaningful and > applications can use it in their framing layers, but instead TLS > exposes a byte stream, because it intentionally looks like TCP. > It is good to keep this in mind, yes. > Of course, 0-RTT unavoidably must stretch the “vaguely”. Suppose there > is a semantically meaningful difference between 0-RTT and 1-RTT data. > I can see why this is attractive. It moves the problem out of TLS. But > this signal is pointless if applications don’t use it. If everyone did > the following, we haven’t solved anything: > > if (InEarlyData()) { > return EarlyDataRead(...); > } else { > return NormalRead(...); > } > Sure, that's not very useful. But, you can also come at it from a different point of view, namely that right now, all applications just do NormalRead(), and EarlyDataRead() for all protocols is simply not defined right now. It "doesn't exist", as it were. We can of course learn from the ongoing experiments that are using EarlyDataRead() for http, as part of designing what the actual formal semantics should be. > So we must consider this signal’s uses. Consider HTTP/2. The goal may > be to tag requests as “0-RTT”, because we wish to reject 0-RTT POSTs > or so. > > What if the server receives data with the 0-RTT boundary spanning an > HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid? If I’m parsing > that, I have to concatenate, and we’re back to that if/else strawman > above. HTTP2 is arguably an easy case. Maybe my protocol is a > compressed stream. Carrying a low-level byte boundary through layers > of application data parsing and processing is not practical. > I think it would be valid to call it a 0-RTT request and reject it, and also valid to call it a 1-RTT request and handle it -- it can be at the implementation's discretion, and I don't know that TLS itself needs to specify which. > We could say that the application profile should modify the protocol > to reject such cases. Now, we’re taking on complexity in every > protocol specification and parser. > But we're *already* taking on complexity in every protocol spec, by requiring an application profile. If you start from the assumption that there is just one data stream and a transition point, then yes, this is a lot of complexity on each application. But I see the starting point as that there only is NormalRead(), and adding EarlyDataRead() requires a protocol extension and implementations of that extension. So, we should be talking about how much complexity is required, not just complaining that we can't drop ReadEarlyOrNormal() in wherever we currently have NormalRead(). > It also brings complexity on the sender side. Perhaps I am halfway > through writing an HTTP/2 frame and, in parallel, I receive the > ServerHello. We moved 0-RTT data out of a ClientHello extension way > back in draft -07 so 0-RTT data can be streamed while waiting for > ServerHello. This is especially useful for HTTP/2 where reads and > writes flow in parallel. This means the sender must synchronize with > the TLS socket to delay the 1-RTT transition. > > Now suppose the TLS stack receives that atomic data and it doesn’t fit > in the 0-RTT send limit. That won’t work, so the sender must query the > early data size and send over 1-RTT if it doesn’t fit. > > Now suppose this HTTP request takes multiple frames to send. One can > send multiple HEADERS frames in HTTP/2. That won’t work, so we > actually need the synchronization to cover the entire request. Maybe > my request has a response body. We need to cover that too, and we need > to know the size for send limit purposes. > > Now suppose assembling the HTTP request takes an asynchronous step > after connection binding. Maybe I’m signing something for tokbind. > Maybe I have some weird browser extension API. In this worldview, all > the while, the HTTP/2 multiplexer must lock out all other requests and > the client Finished, even if the ServerHello has already come in. That > last one is particularly nasty if the server is delaying an > already-sent request until the 1-RTT point (cf. > https://www.ietf.org/mail-archive/web/tls/current/msg21486.html > ). > > Perhaps I keep the request assembling logic, HTTP/2 multiplexers, and > TLS sockets in different threads or processes. Now this > synchronization must span all of these. As one adds layers, the > complexity grows. > Yes, this hypothetical situation is probably an unreasonable amount of complexity. But it presumes some sense of what HTTP/2 will want to permit in early data, a concept which currently is formally undefined -- if HTTP/2 *really* wants to keep requests from splitting the 0/1-RTT boundary, they could define some extremely restricted subset of functionality that only allows a single self-contained frame in early data. I don't expect that to happen, but it would be a valid application profile as far as TLS is concerned. One might also consider an RPC protocol that wants to switch to using TLS 1.3 for security benefits. It would be natural for the application profile for that to say that only certain RPCs are permitted in 0-RTT, and a given marshalled request must not cross the 0/1-RTT boundary. This is clearly a silly example, as it's not really using a "TCP-like stream" of data from TLS, but it is arguably less complex to have the strict separation of semantics between 0- and 1-RTT data. On the other hand, I'm not actually convinced that there are any security benefits gained from the strict separation, so it remains at the core an argument on aesthetics, and not much different from the arguments that have been presented so far. > The root problem here is we’ve changed TLS’s core abstraction. One > might argue all this complexity is warranted for 0-RTT. We are trying > to solve a problem here. But I think we can solve it simpler: > > Our problem is a server wishes not to process some HTTP requests (or > other protocol units) at 0-RTT and needs to detect this case. So check > a boolean signal for whether the connection has currently passed the > 1-RTT point before any unsafe processing. A “1-RTT request” will > always return 1-RTT. A “0-RTT request” will usually return 0-RTT, but > if it spans the boundary or the processing pipeline was just slow, > perhaps we don’t query until after the client Finished. That’s > actually fine. We get the replay protection we need out of the client > Finished. > I agree with Andrei that this scheme satisfies point #3 (or that if it does not, we should rewrite condition #3 to make it a satisfactory option). Your proposal later in the thread seems about as good as the original #3 to me (though I might wordsmith either a bit more). > This solves our problem without the complexity. Two APIs or an > explicit boundary is one way to expose this boolean, but this boolean, > unlike the hard boundary, is much easier to carry across higher-level > protocol layers, and does not imply impractical sender constraints. > It is easier to carry across layers, yes. I don't think the TLS spec should specify one of the two options under discussion (or a different one); we should describe the properties that need to be available for the application to make safe decisions. I suspect that what Brian was trying to say is that this single boolean being easier to carry across layers may also mean it is easier to write code that ends up being unsafe. I don't know; I don't think anyone *can* know, and all we have is supposition and gut instincts. I'm very worried that no matter what APIs libraries offer, some high-profile application/implementation is going to do something insecure and we have another named vulnerability. I'm also not sure that there's any useful we discussion we can have right now on that front, since there's not really hard data. The closest we have seems to be Colm's security analysis of 0-RTT data (and it would be great to have more such analysis), which leaves me thinking that we should strictly disallow "unlimited" (millions) of replays and set some specific limit. (We'd of course have to argue about what that limit is, which would not be fun, but probably would be better than millions of replays.) If I could try to synthesize something concise from these discussions, it seems that a balance of flexibility and simplicity is to provide semantics that let an application write data with a boolean to ndicate that either it must be 1-RTT or the stack should feel free to use either 0- or 1-RTT as it sees fit, and to read data with a boolean to indicate "whether it was 0-RTT or 1-RTT", most likely based on whether the client Finished has been verified but potentially based on record-layer information. Circling back to my earlier question about how much complexity burden we place on application profiles and implementations, this seems not too bad. An application currently uses a write API that is presumed to be "must be 1-RTT" until changed, and locations writing 0-RTT-safe data can switch to using a new API in a targetted fashion, leaving the TLS stack to hold on to 0-RTT-unsafe data (and all subsequent data) until the handshake is finished. The reading story is a little less simple, as the current API doesn't really have the requisite semantics, so the application is living in a gray zone. It seems that a prerequisite for making the API call that says "enable 0-RTT on this server socket" is to convert all read calls to the new form and reject 0-RTT versions of structures that are not permitted by the profile, the converse of the write side. But, it seems that doing anything less is unsafe, and perhaps this is the minimum viable level of complexity. I think it at least addresses the concerns you raise in the context of your HTTP/2 example. Libraries and applications will of course be free to use separate functions for read/write-early/regular if they want, but I think it is fine for TLS to structure the requirements on implementations in such a way that the simpler API is permitted. It is probably also useful to provide guidance to authors of application profiles for how to incorporate 0-RTT data into their protocol. That could be something like "philosophically, TLS provides a TCP-like stream of data to the application, but until the client Finished is verified there are weaker security properties than afterwards, and certain classes of traffic should be deferred until after that point". It could also be something like "TLS provides two qualitatively different streams of data with different security properties; one has a finite length limit dictated by the server and should only receive a limited class of protocol messages of bounded size, and the other resembles historical TLS and is safe for all traffic." I don't actually know what consensus we could come to on that point, or if the chairs are interested in running a contentious consensus call on that question -- after all, a TLS 1.3 spec could be considered complete without such guidance. But, leaving it out might just lead to the argument being rehashed over and over again for each protocol. The deciding point is probably whether we want to ensure that we can support complicated protocols that will not want to limit themselves to the stringent requirements of the latter formulation, such as your HTTP/2 example above. If we can do that safely (in terms of not leaving applications wide open to future security holes), we would end up in the first (single-stream with state change) option. I'm just not sure how I can be comfortably convinced that we can do so safely. Right now, I'm something like uncomfortably mostly convinced, which is not a very pleasant feeling. In a world of millions of replays, maybe it's safer to tell applications that 0-RTT is a distinct separate thing that needs to go in its own bucket. -Ben --------------D10E9368A23D8254F7E81EBC Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/14/2017 02:55 PM, David Benjamin wrote:
On Wed, Jun 14, 2017 at 2:17 AM Petr Špaček <petr.spacek@nic.cz> wrote:


On 13.6.2017 22:55, Ilari Liusvaara wrote:
> On Tue, Jun 13, 2017 at 06:57:05PM +0000, Andrei Popov wrote:
>> Regarding RFC language, I think we could be more specific:
>>
>>
>>
>> 1. A TLS implementation SHOULD/MUST only send 0-RTT application data if the application has explicitly opted in;
>>
>> 2. A TLS implementation SHOULD/MUST only accept 0-RTT application data if the application has explicitly opted in;
>>
>> 3. When delivering 0-RTT application data to the application, a TLS implementation SHOULD/MUST provide a way for the application to distinguish it from the rest of the application data.
>
> First of these has to be MUST, or you get problems like I outlined
> earlier.
>
> And to implement checking for client only sending "safe" data, you need
> the second and third.

I support MUST for the three points above.

The third one is not practical as one moves up layers. Instead, I believe we can get the same benefit with a simpler signal.
 
TLS fundamentally is a transformation from a vaguely TCP-like transport to another vaguely TCP-like transport. Consider TLS records: TLS could have decided record boundaries were meaningful and applications can use it in their framing layers, but instead TLS exposes a byte stream, because it intentionally looks like TCP.
 

It is good to keep this in mind, yes.

Of course, 0-RTT unavoidably must stretch the “vaguely”. Suppose there is a semantically meaningful difference between 0-RTT and 1-RTT data. I can see why this is attractive. It moves the problem out of TLS. But this signal is pointless if applications don’t use it. If everyone did the following, we haven’t solved anything:
 
if (InEarlyData()) {
  return EarlyDataRead(...);
} else {
  return NormalRead(...);
}
 

Sure, that's not very useful.
But, you can also come at it from a different point of view, namely that right now, all applications just do NormalRead(), and EarlyDataRead() for all protocols is simply not defined right now.  It "doesn't exist", as it were.  We can of course learn from the ongoing experiments that are using EarlyDataRead() for http, as part of designing what the actual formal semantics should be.

So we must consider this signal’s uses. Consider HTTP/2. The goal may be to tag requests as “0-RTT”, because we wish to reject 0-RTT POSTs or so.
 
What if the server receives data with the 0-RTT boundary spanning an HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid? If I’m parsing that, I have to concatenate, and we’re back to that if/else strawman above. HTTP2 is arguably an easy case. Maybe my protocol is a compressed stream. Carrying a low-level byte boundary through layers of application data parsing and processing is not practical.
 

I think it would be valid to call it a 0-RTT request and reject it, and also valid to call it a 1-RTT request and handle it -- it can be at the implementation's discretion, and I don't know that TLS itself needs to specify which.

We could say that the application profile should modify the protocol to reject such cases. Now, we’re taking on complexity in every protocol specification and parser.
 

But we're *already* taking on complexity in every protocol spec, by requiring an application profile.  If you start from the assumption that there is just one data stream and a transition point, then yes, this is a lot of complexity on each application.  But I see the starting point as that there only is NormalRead(), and adding EarlyDataRead() requires a protocol extension and implementations of that extension.

So, we should be talking about how much complexity is required, not just complaining that we can't drop ReadEarlyOrNormal() in wherever we currently have NormalRead().

It also brings complexity on the sender side. Perhaps I am halfway through writing an HTTP/2 frame and, in parallel, I receive the ServerHello. We moved 0-RTT data out of a ClientHello extension way back in draft -07 so 0-RTT data can be streamed while waiting for ServerHello. This is especially useful for HTTP/2 where reads and writes flow in parallel. This means the sender must synchronize with the TLS socket to delay the 1-RTT transition.
 
Now suppose the TLS stack receives that atomic data and it doesn’t fit in the 0-RTT send limit. That won’t work, so the sender must query the early data size and send over 1-RTT if it doesn’t fit.
 
Now suppose this HTTP request takes multiple frames to send. One can send multiple HEADERS frames in HTTP/2. That won’t work, so we actually need the synchronization to cover the entire request. Maybe my request has a response body. We need to cover that too, and we need to know the size for send limit purposes.
 
Now suppose assembling the HTTP request takes an asynchronous step after connection binding. Maybe I’m signing something for tokbind. Maybe I have some weird browser extension API. In this worldview, all the while, the HTTP/2 multiplexer must lock out all other requests and the client Finished, even if the ServerHello has already come in. That last one is particularly nasty if the server is delaying an already-sent request until the 1-RTT point (cf. https://www.ietf.org/mail-archive/web/tls/current/msg21486.html).
 
Perhaps I keep the request assembling logic, HTTP/2 multiplexers, and TLS sockets in different threads or processes. Now this synchronization must span all of these. As one adds layers, the complexity grows.
 

Yes, this hypothetical situation is probably an unreasonable amount of complexity.  But it presumes some sense of what HTTP/2 will want to permit in early data, a concept which currently is formally undefined -- if HTTP/2 *really* wants to keep requests from splitting the 0/1-RTT boundary, they could define some extremely restricted subset of functionality that only allows a single self-contained frame in early data.  I don't expect that to happen, but it would be a valid application profile as far as TLS is concerned.

One might also consider an RPC protocol that wants to switch to using TLS 1.3 for security benefits.  It would be natural for the application profile for that to say that only certain RPCs are permitted in 0-RTT, and a given marshalled request must not cross the 0/1-RTT boundary.  This is clearly a silly example, as it's not really using a "TCP-like stream" of data from TLS, but it is arguably less complex to have the strict separation of semantics between 0- and 1-RTT data.
On the other hand, I'm not actually convinced that there are any security benefits gained from the strict separation, so it remains at the core an argument on aesthetics, and not much different from the arguments that have been presented so far.

The root problem here is we’ve changed TLS’s core abstraction. One might argue all this complexity is warranted for 0-RTT. We are trying to solve a problem here. But I think we can solve it simpler:
 
Our problem is a server wishes not to process some HTTP requests (or other protocol units) at 0-RTT and needs to detect this case. So check a boolean signal for whether the connection has currently passed the 1-RTT point before any unsafe processing. A “1-RTT request” will always return 1-RTT. A “0-RTT request” will usually return 0-RTT, but if it spans the boundary or the processing pipeline was just slow, perhaps we don’t query until after the client Finished. That’s actually fine. We get the replay protection we need out of the client Finished.
 

I agree with Andrei that this scheme satisfies point #3 (or that if it does not, we should rewrite condition #3 to make it a satisfactory option).  Your proposal later in the thread seems about as good as the original #3 to me (though I might wordsmith either a bit more).

This solves our problem without the complexity. Two APIs or an explicit boundary is one way to expose this boolean, but this boolean, unlike the hard boundary, is much easier to carry across higher-level protocol layers, and does not imply impractical sender constraints.


It is easier to carry across layers, yes.  I don't think the TLS spec should specify one of the two options under discussion (or a different one); we should describe the properties that need to be available for the application to make safe decisions.

I suspect that what Brian was trying to say is that this single boolean being easier to carry across layers may also mean it is easier to write code that ends up being unsafe.  I don't know; I don't think anyone *can* know, and all we have is supposition and gut instincts.  I'm very worried that no matter what APIs libraries offer, some high-profile application/implementation is going to do something insecure and we have another named vulnerability.  I'm also not sure that there's any useful we discussion we can have right now on that front, since there's not really hard data.  The closest we have seems to be Colm's security analysis of 0-RTT data (and it would be great to have more such analysis), which leaves me thinking that we should strictly disallow "unlimited" (millions) of replays and set some specific limit.  (We'd of course have to argue about what that limit is, which would not be fun, but probably would be better than millions of replays.)


If I could try to synthesize something concise from these discussions, it seems that a balance of flexibility and simplicity is to provide semantics that let an application write data with a boolean to ndicate that either it must be 1-RTT or the stack should feel free to use either 0- or 1-RTT as it sees fit, and to read data with a boolean to indicate "whether it was 0-RTT or 1-RTT", most likely based on whether the client Finished has been verified but potentially based on record-layer information.

Circling back to my earlier question about how much complexity burden we place on application profiles and implementations, this seems not too bad.  An application currently uses a write API that is presumed to be "must be 1-RTT" until changed, and locations writing 0-RTT-safe data can switch to using a new API in a targetted fashion, leaving the TLS stack to hold on to 0-RTT-unsafe data (and all subsequent data) until the handshake is finished.  The reading story is a little less simple, as the current API doesn't really have the requisite semantics, so the application is living in a gray zone.  It seems that a prerequisite for making the API call that says "enable 0-RTT on this server socket" is to convert all read calls to the new form and reject 0-RTT versions of structures that are not permitted by the profile, the converse of the write side.  But, it seems that doing anything less is unsafe, and perhaps this is the minimum viable level of complexity.  I think it at least addresses the concerns you raise in the context of your HTTP/2 example.  Libraries and applications will of course be free to use separate functions for read/write-early/regular if they want, but I think it is fine for TLS to structure the requirements on implementations in such a way that the simpler API is permitted.


It is probably also useful to provide guidance to authors of application profiles for how to incorporate 0-RTT data into their protocol.  That could be something like "philosophically, TLS provides a TCP-like stream of data to the application, but until the client Finished is verified there are weaker security properties than afterwards, and certain classes of traffic should be deferred until after that point".  It could also be something like "TLS provides two qualitatively different streams of data with different security properties; one has a finite length limit dictated by the server and should only receive a limited class of protocol messages of bounded size, and the other resembles historical TLS and is safe for all traffic."  I don't actually know what consensus we could come to on that point, or if the chairs are interested in running a contentious consensus call on that question -- after all, a TLS 1.3 spec could be considered complete without such guidance.  But, leaving it out might just lead to the argument being rehashed over and over again for each protocol.  The deciding point is probably whether we want to ensure that we can support complicated protocols that will not want to limit themselves to the stringent requirements of the latter formulation, such as your HTTP/2 example above.  If we can do that safely (in terms of not leaving applications wide open to future security holes), we would end up in the first (single-stream with state change) option.  I'm just not sure how I can be comfortably convinced that we can do so safely.  Right now, I'm something like uncomfortably mostly convinced, which is not a very pleasant feeling.  In a world of millions of replays, maybe it's safer to tell applications that 0-RTT is a distinct separate thing that needs to go in its own bucket.

-Ben
--------------D10E9368A23D8254F7E81EBC-- From nobody Thu Jun 15 17:16:20 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95EC0126E3A for ; Thu, 15 Jun 2017 17:16:17 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 VUab1vKTS2s4 for ; Thu, 15 Jun 2017 17:16:16 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 A9F731267BB for ; Thu, 15 Jun 2017 17:16:15 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id o83so17271166lff.3 for ; Thu, 15 Jun 2017 17:16:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Ttr+tIdOCaNp5E3YSWuTRks2gkvRK+UtE+jI6fHjjZQ=; b=KkfZwAoR4fCbzEYXTwW6W95TuJFeGlbSSDiUttFnaRvvc5fdFkbmceTi79NgV91LIt 0DgWPprsaou3PgNchR6h8NueUbqIt20GfTmLn8hPD8gyhgIKBLRdMqXbyaYUR03ussIG KiKu7efiiNIgpGiNqQ+y2OIWrxtjR2T3okg9crdlqbQmmmhJ73JiSYGzcyUjgsdDAxUJ c47C9DzWRkH5RMp9aUddBLpdAy36kH19uqARI4THyTw6YoRXYomXsrpbDcQB48KQlptQ MVFHhomw4fZBOqOO8NyG0geAFeadP0D8SLlAoYIUZIwnld59coQO1k1Hi9+c7b63HrLt 1A9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Ttr+tIdOCaNp5E3YSWuTRks2gkvRK+UtE+jI6fHjjZQ=; b=cuzqJOjLlxD+W09Ukhj+a7rK7UlmJR1a1XwJfBjLUuFuZPKRswCBZc7RuM8uCO9en8 qpdi2RDnd6aiCF/9LkdjkAHzvbzr9gvYo0aAdDC3/+mA6qFKPL+FFkzcgruDciSs/8DV dPaLzTtm+5KEcSGnjupM/LZyrT24/rfRET8pXJ4LeMQ/u4ZL5YoK8Cl5FKRa0clVVDkM eTzqtxn6l6gWhJUoS0KWRXoG7HJMAluIv5mwJQRXaWyRArvmlhzFhUz1Q52LewzBaxSW 70wDVFf4a3QpSJKkKguwVh5/r8fkM7a9GGmsT7pv8zNhAR8Wg9DJuyQv99hLa9aKnlUZ Hixw== X-Gm-Message-State: AKS2vOxa+/Sn9CvkArZf8yxd886ApeRXrY+S8X7MA/uli03Z2lMkaK1p NqGlOOWBtrPuZyn8xalzrsTHqp4YzQ== X-Received: by 10.25.196.17 with SMTP id u17mr2189913lff.19.1497572173952; Thu, 15 Jun 2017 17:16:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Thu, 15 Jun 2017 17:16:12 -0700 (PDT) In-Reply-To: References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> From: Martin Thomson Date: Fri, 16 Jun 2017 10:16:12 +1000 Message-ID: To: David Benjamin Cc: Andrei Popov , =?UTF-8?B?UGV0ciDFoHBhxI1law==?= , "tls@ietf.org" Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 16 Jun 2017 00:16:18 -0000 On 15 June 2017 at 08:23, David Benjamin wrote: > When accepting 0-RTT as a server, a TLS implementation SHOULD/MUST provide a > way for the application to determine if the client Finished has been > processed. I'm going to throw my support behind this distinction. Though I would phrase this more simply as "the handshake is complete". From nobody Tue Jun 20 17:10:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 658D71289B5 for ; Tue, 20 Jun 2017 17:10: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, 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=vimino.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 mfLQ_bNRNn0N for ; Tue, 20 Jun 2017 17:10:04 -0700 (PDT) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 7CA7D1315B9 for ; Tue, 20 Jun 2017 17:10:03 -0700 (PDT) Received: by mail-lf0-x22e.google.com with SMTP id m77so84211870lfe.0 for ; Tue, 20 Jun 2017 17:10:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vimino.com; s=google; h=mime-version:from:date:message-id:subject:to; bh=BLvFl3K43Ji0biz8xdlCv7ZC8uNi2G1cScCzC4JGAXY=; b=fo/YoNV2d2XM3PFcqEsGp0vMrfXp0gqA+IEg0Mrm8nINBZzLPF1sT5wlnvgcHK/Qm/ cdpFJRCb2vBYFyx/h+hilaKLDwD8rHQx+lT82140fvzoNw1UgeqRSmGDByjjSrAlLBGx AyZfMkGyd33rmdRpD0n+mWVVXYW8uSd2w9H5s= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=BLvFl3K43Ji0biz8xdlCv7ZC8uNi2G1cScCzC4JGAXY=; b=tjEnpiQUt0x5MQ3WRcrXZ6PhUuyzxXaOtj3W6deijr4r3o66/GHdfsDaIOGbdDx3ni U3Wl3Su66RaFUL8efU/hd5UrKBREUTiM8LPUjvvSVKDwQouEWQwRJ6+CKViViToAKE2d LrRDktlp8wKCbE4/aQOBKPjrtXmiGwmEcnHjz80ZXPh+eeapJAfTkHBxnw7dzM0ekcYd n6WvZD1dn1vEbjB1zgEb4dmK1aez4STiKkvG6qOuE+PxK1ulSh7kEO1arPQg5d4E9Irj L+lm7ALOCFWHtpvPQXHv9wxRg82fjjPWdq4GLra4zN2AGCBH1ELja+C7b3FePPhWIzhd TH/A== X-Gm-Message-State: AKS2vOxRt4GzLLL40HWldJ+TWeTQMLbx8aSbEBRWjfak4GC7D6KBerVG Bwp8jKtRotGzE+aeRmJkGTxW/wRvnblQSxc= X-Received: by 10.25.92.18 with SMTP id q18mr641317lfb.13.1498003801586; Tue, 20 Jun 2017 17:10:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.22.92 with HTTP; Tue, 20 Jun 2017 17:10:00 -0700 (PDT) X-Originating-IP: [148.87.23.8] From: Xuelei Fan Date: Tue, 20 Jun 2017 17:10:00 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0e7e2077584305526d30be" Archived-At: Subject: [TLS] The use of "trusted_ca_keys" for server certificate selection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 21 Jun 2017 00:10:06 -0000 --94eb2c0e7e2077584305526d30be Content-Type: text/plain; charset="UTF-8" Hi, In section 4.4.2.2, "Server Certificate Selection", of TLS 1.3 draft: https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.2.2 It is stated: - The "server_name" and "trusted_ca_keys" extensions [RFC6066 ] are used to guide certificate selection. As servers MAY require the presence of the "server_name" extension, clients SHOULD send this extension, when applicable. The "trusted_ca_keys" extension is not used in TLS 1.3, and is replaced with the "certificate_authorities" extension (Section 4.2.4): The "trusted_ca_keys" extension, which serves a similar purpose [RFC6066 ], but is more complicated, is not used in TLS 1.3 (although it may appear in ClientHello messages from clients which are offering prior versions of TLS). I guess it is a typo or a missed update to use the the "trusted_ca_keys" extension for server certificate selection in section 4.4.2.2. The "certificate_authorities" extension should be used instead. Regards, Xuelei Fan --94eb2c0e7e2077584305526d30be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

In section 4.4.2.2, "Server Ce= rtificate Selection", of TLS 1.3 draft:
=C2=A0 =C2=A0ht= tps://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.2.2

It is stated:
   The "trusted_ca_keys" extension, which s=
erves a similar purpose
   [RFC6066=
], but is more complicated, is not used in TLS 1.3 (although
   it may appear in ClientHello messages from clients which are offering
   prior versions of TLS).

I guess it is a t= ypo or a missed update to use the the "trusted_ca_keys" extension= for server certificate selection in section 4.4.2.2.=C2=A0 The "certi= ficate_authorities" extension should be used instead.

Regards,
Xuelei Fan


--94eb2c0e7e2077584305526d30be-- From nobody Tue Jun 20 17:19:00 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F4FC129501 for ; Tue, 20 Jun 2017 17:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 DChMMZVDWlcK for ; Tue, 20 Jun 2017 17:18:57 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 3438312956D for ; Tue, 20 Jun 2017 17:18:57 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5L0HIpR023840; Wed, 21 Jun 2017 01:18:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=ohG05bJFTl1lfxisoF+0JFkgusZYuvxmyUmkP6G2Jj0=; b=X4xRhBo5sl3qVtLbmIQXNSAyoiqLWWYbJS62J0GPkf1FH+F8uxNlyM3hMJEeOk7ekVd2 lTPB9Pwaa7zQWqgSthR3T/+Hfj1hJjmklhcXgebzj+FG2cZ1ax3mRDu6XQvVA7inPhqH WW9Ae+ac1QOOsPo+dlZHTzMUn9bQmNy/kork7KA+uoZ/LOskkfhe2zC+a/nPGo2EzJJ9 vDwLOfVt01VeMZTaCAJoGmsrqCO3TqBk9+uQU1hUqwcWAlAvHfnnC17xzJ05kCjNNDOF lLbV3JNxCp7DxT9bHeiC3anT5xGWH4NO85HJ0LUkOmvoLeMcZYi19WWemv2DOJzdLD4x sw== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2b75axbt0w-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Jun 2017 01:18:55 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5L0Fvjv009313; Tue, 20 Jun 2017 20:18:54 -0400 Received: from prod-mail-relay14.akamai.com ([172.27.17.39]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b4yrv0y82-1; Tue, 20 Jun 2017 20:18:54 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay14.akamai.com (Postfix) with ESMTP id 02BE580052; Tue, 20 Jun 2017 18:18:53 -0600 (MDT) To: Xuelei Fan , "tls@ietf.org" References: From: Benjamin Kaduk Message-ID: <52712e1a-796a-e72d-2c80-4eda1127d9b2@akamai.com> Date: Tue, 20 Jun 2017 19:18:53 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------78FF899C5282A08F5689224C" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706210003 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-20_13:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706210003 Archived-At: Subject: Re: [TLS] The use of "trusted_ca_keys" for server certificate selection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 21 Jun 2017 00:18:59 -0000 This is a multi-part message in MIME format. --------------78FF899C5282A08F5689224C Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/20/2017 07:10 PM, Xuelei Fan wrote: > Hi, > > In section 4.4.2.2, "Server Certificate Selection", of TLS 1.3 draft: > https://tools.ietf.org/html/draft-ietf-tls-tls13-20#section-4.4.2.2 > > > It is stated: > - The "server_name" and "trusted_ca_keys" extensions [RFC6066 > ] are > used to guide certificate selection. As servers MAY require the > presence of the "server_name" extension, clients SHOULD send this > extension, when applicable. > The "trusted_ca_keys" extension is not used in TLS 1.3, and is > replaced with the "certificate_authorities" extension (Section 4.2.4): > The "trusted_ca_keys" extension, which serves a similar purpose > [RFC6066 > ], but is more complicated, is not used in TLS 1.3 (although > it may appear in ClientHello messages from clients which are offering > prior versions of TLS). > > I guess it is a typo or a missed update to use the the > "trusted_ca_keys" extension for server certificate selection in > section 4.4.2.2. The "certificate_authorities" extension should be > used instead. > Missed update most likely; the change log indicates that the switch from trusted_ca_keys to certificate_authorities was made during the history of this document. I filed https://github.com/tlswg/tls13-spec/pull/1032 so the change doesn't get lost. -Ben --------------78FF899C5282A08F5689224C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/20/2017 07:10 PM, Xuelei Fan wrote:
Hi,

In section 4.4.2.2, "Server Certificate Selection", of TLS 1.3 draft:

It is stated:
   -  The "server_name" and "trusted_ca_keys" extensions [RFC6066] are
      used to guide certificate selection.  As servers MAY require the
      presence of the "server_name" extension, clients SHOULD send this
      extension, when applicable.
The "trusted_ca_keys" extension is not used in TLS 1.3, and is replaced with the "certificate_authorities" extension (Section 4.2.4):
   The "trusted_ca_keys" extension, which serves a similar purpose
   [RFC6066], but is more complicated, is not used in TLS 1.3 (although
   it may appear in ClientHello messages from clients which are offering
   prior versions of TLS).

I guess it is a typo or a missed update to use the the "trusted_ca_keys" extension for server certificate selection in section 4.4.2.2.  The "certificate_authorities" extension should be used instead.


Missed update most likely; the change log indicates that the switch from trusted_ca_keys to certificate_authorities was made during the history of this document.

I filed https://github.com/tlswg/tls13-spec/pull/1032 so the change doesn't get lost.

-Ben
--------------78FF899C5282A08F5689224C-- From nobody Tue Jun 20 17:40:51 2017 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 759621294E1; Tue, 20 Jun 2017 17:40:44 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149800564443.15906.11126472202021638034@ietfa.amsl.com> Date: Tue, 20 Jun 2017 17:40:44 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 21 Jun 2017 00:40:44 -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 : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-01.txt Pages : 6 Date : 2017-06-20 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-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 Tue Jun 20 17:53:35 2017 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 800E1131651; Tue, 20 Jun 2017 17:53:27 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149800640748.15620.17719461440415573566@ietfa.amsl.com> Date: Tue, 20 Jun 2017 17:53:27 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-exported-authenticator-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 21 Jun 2017 00:53:28 -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 : Exported Authenticators in TLS Author : Nick Sullivan Filename : draft-ietf-tls-exported-authenticator-02.txt Pages : 6 Date : 2017-06-20 Abstract: This document describes a mechanism in Transport Layer Security (TLS) to provide an exportable proof of ownership of a certificate that can be transmitted out of band and verified by the other party. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-exported-authenticator-02 https://datatracker.ietf.org/doc/html/draft-ietf-tls-exported-authenticator-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-exported-authenticator-02 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 Wed Jun 21 21:25:32 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51F29126BF3 for ; Wed, 21 Jun 2017 21:25:31 -0700 (PDT) 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, 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 VYduEpK46nqE for ; Wed, 21 Jun 2017 21:25:29 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 3551F120721 for ; Wed, 21 Jun 2017 21:25:29 -0700 (PDT) Received: from xsmtp12.mail2web.com ([168.144.250.177]) by mx36.antispamcloud.com with esmtps (TLSv1.2:AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1dNtgN-0000uI-GB for tls@ietf.org; Thu, 22 Jun 2017 06:25:28 +0200 Received: from internal.xmail11.myhosting.com ([10.5.2.49] helo=xmail11.myhosting.com) by xsmtp12.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dNtgJ-00063J-A4 for tls@ietf.org; Thu, 22 Jun 2017 00:25:26 -0400 Received: (qmail 26332 invoked from network); 22 Jun 2017 04:25:22 -0000 Received: from unknown (HELO [192.168.1.106]) (Authenticated-user:_huitema@huitema.net@[172.56.42.228]) (envelope-sender ) by xmail11.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 22 Jun 2017 04:25:22 -0000 References: <149810504637.30481.937244297632371838.idtracker@ietfa.amsl.com> To: "tls@ietf.org" From: Christian Huitema X-Forwarded-Message-Id: <149810504637.30481.937244297632371838.idtracker@ietfa.amsl.com> Message-ID: <422ef2c7-4d99-20d2-8a39-ffd61277e0bd@huitema.net> Date: Wed, 21 Jun 2017 21:25:21 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <149810504637.30481.937244297632371838.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------4E64420BBEBA63C626602835" X-Originating-IP: 168.144.250.177 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: ham X-SpamExperts-Outgoing-Evidence: Combined (0.04) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJbMzHFUa97P3bfY1LzB69ykND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23+2xzyYwF4OD4fWj6viVZCZzZ8rfsXcrYidfw YfZGgWI4a3erO6t2fQxZkXetsmUlYOEkjsX7F8KmpUaZQHV+SaoNpL7PRmmTib7l1mO88Em2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpCbsjdvAic40+cHi4LtB9yD6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGydcTRWfLWxROAuCJSpTvxp3eNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+xII1yJ8udUSd8siDlV+9cBL pGLKbiMLMKI7KIsgfDrl6J1fhOzjF0b4LXcjJZ5lorSoCYRNcdNYFM9Dkt7piwO7IVXITpPh1qZI 46Rz116sVsEMP/VCYoG832SoDCsEjl9e6qt4y0llDRDaFA2tZcPw1eMmeklA3MQEw0NwP6IDPa8Q GWJY81iEsidlXaP4/sbpzuwjGHyC+YDvAYilEDNpxNDZdajQS3WSizkDbMOPTRpUChnn7dZMk3sz 8NLrGw== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-huitema-tls-sni-encryption-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2017 04:25:31 -0000 This is a multi-part message in MIME format. --------------4E64420BBEBA63C626602835 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit We has many discussions of SNI encryption on this list recently, and that was enough motivation to write a draft about it. I am pretty sure that this will be met with wide approval and no discussion at all :-). -- Christian Huitema -------- Forwarded Message -------- Subject: New Version Notification for draft-huitema-tls-sni-encryption-00.txt Date: Wed, 21 Jun 2017 21:17:26 -0700 From: internet-drafts@ietf.org To: Christian Huitema , Eric Rescorla A new version of I-D, draft-huitema-tls-sni-encryption-00.txt has been successfully submitted by Christian Huitema and posted to the IETF repository. Name: draft-huitema-tls-sni-encryption Revision: 00 Title: SNI Encryption in TLS Through Tunneling Document date: 2017-06-20 Group: Individual Submission Pages: 19 URL: https://www.ietf.org/internet-drafts/draft-huitema-tls-sni-encryption-00.txt Status: https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/ Htmlized: https://tools.ietf.org/html/draft-huitema-tls-sni-encryption-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-huitema-tls-sni-encryption-00 Abstract: This draft describes the general problem of encryption of the Server Name Identification (SNI) parameter. The proposed solutions hide a Hidden Service behind a Fronting Service, only disclosing the SNI of the Fronting Service to external observers. The draft starts by listing known attacks against SNI encryption, and then presents two potential solutions that might mitigate these attacks. The first solution is based on TLS in TLS "quasi tunneling", and the second solution is based on "combined tickets". These solutions only require minimal extensions to the TLS protocol. 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 --------------4E64420BBEBA63C626602835 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

We has many discussions of SNI encryption on this list recently, and that was enough motivation to write a draft about it. I am pretty sure that this will be met with wide approval and no discussion at all :-).

-- Christian Huitema

-------- Forwarded Message --------

Subject: New Version Notification for draft-huitema-tls-sni-encryption-00.txt
Date: Wed, 21 Jun 2017 21:17:26 -0700
From: internet-drafts@ietf.org
To: Christian Huitema <huitema@huitema.net>, Eric Rescorla <ekr@rtfm.com> 


A new version of I-D, draft-huitema-tls-sni-encryption-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name:		draft-huitema-tls-sni-encryption
Revision:	00
Title:		SNI Encryption in TLS Through Tunneling
Document date:	2017-06-20
Group:		Individual Submission
Pages:		19
URL:            https://www.ietf.org/internet-drafts/draft-huitema-tls-sni-encryption-00.txt
Status:         https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/
Htmlized:       https://tools.ietf.org/html/draft-huitema-tls-sni-encryption-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-huitema-tls-sni-encryption-00


Abstract:
   This draft describes the general problem of encryption of the Server
   Name Identification (SNI) parameter.  The proposed solutions hide a
   Hidden Service behind a Fronting Service, only disclosing the SNI of
   the Fronting Service to external observers.  The draft starts by
   listing known attacks against SNI encryption, and then presents two
   potential solutions that might mitigate these attacks.  The first
   solution is based on TLS in TLS "quasi tunneling", and the second
   solution is based on "combined tickets".  These solutions only
   require minimal extensions to the TLS protocol.

                                                                                  


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
--------------4E64420BBEBA63C626602835-- From nobody Thu Jun 22 00:32:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC5E01286CA for ; Thu, 22 Jun 2017 00:32:15 -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 1zYQIDi-_U92 for ; Thu, 22 Jun 2017 00:32:14 -0700 (PDT) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::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 ADBC2126CD8 for ; Thu, 22 Jun 2017 00:32:13 -0700 (PDT) Received: by mail-lf0-x232.google.com with SMTP id m77so4281002lfe.0 for ; Thu, 22 Jun 2017 00:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7Ugnq1ROdEiRPAemNxTQk1vKaQb0Nd/YojtwHrbESaU=; b=hHm/iqV1LkJqU0hb7WdDrokZUHdHgnBaDz/hdxV8bjL+JI4UQv+SWgg5RMuzjkw6zC /j/U4zEFpoy4UF26Gygrsj0LpjEQJPY1si1dQJ/pgJB57ttvu12UspPUKIb/wNo6b25A TLv3TPyBcyKxbGvjTzEifDtinDPOQDyKsx7+ug8aJUdPC4LLwn6hbnKeO5sg791AfLys nmZtLj8Jy2fkYc+AGYiJFJxGzHusurz1TOftYfoDLYxMWexkTmFr+4ZV8V5PN6p9dPCp cNUH/hPEXbVOKxoff17w6bHBk4WDmuOn6L7oVT9BlSLYv+iLzw00454AUom+PmHntTLp bxAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7Ugnq1ROdEiRPAemNxTQk1vKaQb0Nd/YojtwHrbESaU=; b=ry8+0RaJXvmX4Y/bH2/vE+1uoW8KHZbF+ebValO7PCfu9Cm/2zkbPCUfg6C1UAYj5E 0Rd1i29aru+0cAcg5MBRZiLnFce2xVrdHXLL9WLQqhTW4wKtedrYTuDeTZ1wTvvp/WhF sgwSuPJrqGkm0RVb8CFlhp4Zm0DNz8EhV+GpINjuK+HWx0Dc87tnWyi+tAP3H8WYl4q9 wkJoVPtHf3PI6RklQOatPzS/zrFW4/v4bMNNIoYABhvMenTc2NaaNcjwT+MndofqOQ2Z 5ojORFOaAt/+jaUcOK2PqG51UDY/gv/4doj2rgWcyDeA7vNq3ybMDcvi6r49SmIZPknh Af9w== X-Gm-Message-State: AKS2vOxJ20v09dAlmxZk6d+LyuxN0WvBERBIawDhXIkWDO8ANoVHV1ry 8B5DOwVBoXuftvSj1oUDd2j8hAaJHI4aMag= X-Received: by 10.46.77.70 with SMTP id a67mr430475ljb.103.1498116731775; Thu, 22 Jun 2017 00:32:11 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Thu, 22 Jun 2017 00:32:11 -0700 (PDT) In-Reply-To: <149811425736.30341.16596521802774811431.idtracker@ietfa.amsl.com> References: <149811425736.30341.16596521802774811431.idtracker@ietfa.amsl.com> From: Martin Thomson Date: Thu, 22 Jun 2017 17:32:11 +1000 Message-ID: To: "tls@ietf.org" , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: [TLS] Fwd: New Version Notification for draft-thomson-http-replay-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 22 Jun 2017 07:32:16 -0000 FYI, Mark, Willy, and I have put together a draft that describes how HTTP works with early data (or 0-RTT). The main thing of interest is the technique we recommend for avoiding exposure to replays, particularly given that HTTP is often intermediated. If you have specific comments about the draft, I'd appreciate it if you could take those to the HTTP working group . Of course, you should feel free to start another massive thread about the various ways in which you think early data represents the beginning of the end for modern civilization. That seems to be the usual reaction to this sort of email. --Martin ---------- Forwarded message ---------- From: Date: 22 June 2017 at 16:50 Subject: New Version Notification for draft-thomson-http-replay-00.txt Name: draft-thomson-http-replay Revision: 00 Title: Using Early Data in HTTP Document date: 2017-06-22 Group: Individual Submission Pages: 9 URL: https://www.ietf.org/internet-drafts/draft-thomson-http-replay-00.txt Status: https://datatracker.ietf.org/doc/draft-thomson-http-replay/ Htmlized: https://tools.ietf.org/html/draft-thomson-http-replay-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-thomson-http-replay-00 Abstract: This document explains the risks of using early data for HTTP and describes techniques for reducing them. In particular, it defines a mechanism that enables clients to communicate with servers about early data, to assure correct operation. From nobody Thu Jun 22 19:10:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E1CB129C09 for ; Thu, 22 Jun 2017 19:10:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.689 X-Spam-Level: X-Spam-Status: No, score=-4.689 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=-2.8, SPF_HELO_PASS=-0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=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 5aZ_jAxviFBM for ; Thu, 22 Jun 2017 19:10:34 -0700 (PDT) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0067.outbound.protection.outlook.com [104.47.32.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B915129329 for ; Thu, 22 Jun 2017 19:10:34 -0700 (PDT) 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=c1Un90kivqB9A9xriJn0H8JZb0uL9ihYbUgVfYlZaiU=; b=R600QF8VGp1A3biEBsPAP3lrZAZEFUIzo8M6IJp8mDHi5XqZlQ3KHSoRacL5Fa3ukcJvxaEhx0QIOOS+F/HL3EweX8lLdILZ/UcVBEmasq5bdRD0xhK37IAloHTwzjl2RQuGk438ckhyYJMD2iEzChD0aK1OPYGmtO4+4/KVn5Y= Received: from CY4PR10MB1734.namprd10.prod.outlook.com (10.172.69.9) by CY4PR10MB1733.namprd10.prod.outlook.com (10.172.69.8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1178.14; Fri, 23 Jun 2017 02:10:32 +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.1178.023; Fri, 23 Jun 2017 02:10:33 +0000 From: Timothy Jackson To: Martin Thomson , David Benjamin CC: "tls@ietf.org" Thread-Topic: [TLS] Separate APIs for 0-RTT Thread-Index: AQHS5B826ocFwaUKVUu/TtaM+BWK4KIit00AgAABTICAAD7KgIAABLeAgAAS9ICAAAKWgIAABRGAgAAA6oCAAAfUAIAAA2CAgAACoYCAACEVAIAAnPmAgADkkgCAABJdAIAAFyAAgAGxtQCACyBEwA== Date: Fri, 23 Jun 2017 02:10:32 +0000 Message-ID: References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=mobileiron.com; x-originating-ip: [204.8.168.222] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; CY4PR10MB1733; 7:IgU3R2XRAhkdhyylb9+JiAD0WJqwx2cjauKKXu3U0tjupHt7qfwdOgSNrAqE7d3o7g0ckCQb81zYrxTMJwZqBVOav1+MJZFJP5sJ9XiXxMz3+M5Bemq+7P9dmyOA1REIG+kwcvwv4iNIJGbiGRtpGPEvQZ1NtCnq8Np9bPc0UdVZEHzYKDt2VinyOJp2CwxCwshEaYIocloLclcEsvkhcWYWvaJWXz+KmTtYiv+x4cvBfgGWowYmX4pmJDRmiSo/0xbNShbLbeh4P7kgPoc1khNrV3AbeaX3NPeVphx8b6QerKxHZnFHApXlML464EByU9cU4EXHknk7z5zj3OFxRA4rl/fiP44Xnblkzz5rU2hUpeoqdTdbesAjqvOUXtnyNaO3x9B5CDTye0Z749hldJXosHNCSiCjhMcQijcGrtvkmebKbPT6DJ9z2vqiLkpKAHFY3fg2Pzg0n3vaRRjiL31focj+WDLbKxM9L0/jY4zLq7Qc3wTm6spQuXkZ7iwcbV86pTjUfSFFTEn+T356yxl2vfKR/Msr6Qjo1dWmFqloq2UxsVBHBsT2vLBcjUD4zqtN3EQCXyG+1/b6v5qa1pMsXICsRBBu0cEhgzsCup7UhhuV3DjP5oGK+0bscd/pZ7RjIVjFDTKBNpZFM+69LiUfNqfG0gdYiku4LH8agO8wG37wnwGYQcD6cQ8sBzsfVPZlBVNlavyNaUhyQcKLoIvz4rEPfZOc8APGEM5k7N9MbHEDVgrygoaItqcq5bAeysDfTDjW+oO2SnayZCM9Hmka9rmFyiOvxQ+HGUxL8cU= x-ms-office365-filtering-correlation-id: 9fd1a656-c55a-49f2-1475-08d4b9dd0777 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(2017030254075)(201703131423075)(201703031133081)(201702281549075); SRVR:CY4PR10MB1733; x-ms-traffictypediagnostic: CY4PR10MB1733: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(601004)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(100000703101)(100105400095)(10201501046)(6041248)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123560025)(20161123558100)(20161123555025)(20161123564025)(6072148)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:CY4PR10MB1733; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:CY4PR10MB1733; x-forefront-prvs: 0347410860 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39840400002)(39410400002)(39400400002)(39450400003)(39850400002)(24454002)(377454003)(229853002)(39060400002)(6436002)(966005)(2950100002)(2906002)(25786009)(3280700002)(3660700001)(478600001)(77096006)(6486002)(63666004)(122556002)(14454004)(93886004)(51650200002)(4326008)(7906003)(6506006)(3846002)(86362001)(7736002)(102836003)(5660300001)(53546010)(6116002)(606005)(66066001)(2900100001)(8936002)(33646002)(68736007)(6512007)(95246002)(53936002)(50986999)(189998001)(6306002)(38730400002)(99286003)(6246003)(236005)(54896002)(54356999)(9686003)(76176999)(81166006)(8676002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR10MB1733; H:CY4PR10MB1734.namprd10.prod.outlook.com; FPR:; SPF:None; MLV:ovrnspm; PTR:InfoNoRecords; LANG:en; spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_bi1n55pr8mut29311935117k1498183830709emailandroidcom_" MIME-Version: 1.0 X-OriginatorOrg: mobileiron.com X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jun 2017 02:10:32.7725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 8392379d-8a98-4cb4-8cfe-5e7fa92e4e60 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR10MB1733 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2017 02:10:38 -0000 --_000_bi1n55pr8mut29311935117k1498183830709emailandroidcom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 and a preference for MUST, just so people understand the importance. Since we're agreed that 0-RTT data and 1-RTT data have (almost) the same se= curity properties once the handshake completes, it seems to me, unless I've= missed something, that a lot of protocols will accept 0-RTT but withhold t= he response until after the handshake completes. I expect this massively si= mplifies the analysis the for the app developers. Clientdata =3D readData() Reply =3D CreateReply(client data); //time intensive operation (e.g. Databa= se, CDN cache lookup) While(!clientFinished()) Wait(); //do nothing until 1-RTT finished Send(reply) This has the benefit of allowing slow lookups/processing to happen against = 0-RTT, while delaying the "risky actions" until after 1-RTT. If I'm not mis= taken, it would also make timing attacks harder since any cache misses woul= d be at least partly masked by the time required for the 1-RTT handshake. Dual streams seems to just add complexity here. What I really care about as= a developer is whether I can fully trust the 0-RTT data, which is determin= ed by whether the handshake is finished. Cheers, Tim -- Tim Jackson Senior Product Security Architect, MobileIron Inc. ________________________________ From: "Martin Thomson" > Date: Thursday, June 15, 2017 at 5:16:29 PM To: "David Benjamin" > Cc: "tls@ietf.org" > Subject: Re: [TLS] Separate APIs for 0-RTT On 15 June 2017 at 08:23, David Benjamin wrote: > When accepting 0-RTT as a server, a TLS implementation SHOULD/MUST provid= e a > way for the application to determine if the client Finished has been > processed. I'm going to throw my support behind this distinction. Though I would phrase this more simply as "the handshake is complete". _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_bi1n55pr8mut29311935117k1498183830709emailandroidcom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1 and a preference for MUST, just so people understand the importance= .

Since we're agreed that 0-RTT data and 1-RTT data have (almost) the same se= curity properties once the handshake completes, it seems to me, unless I've= missed something, that a lot of protocols will accept 0-RTT but withhold t= he response until after the handshake completes. I expect this massively simplifies the analysis the for the app= developers.

Clientdata =3D readData()
Reply =3D CreateReply(client data); //time intensive operation (e.g. Databa= se, CDN cache lookup)

While(!clientFinished())
Wait(); //do nothing until 1-RTT finished

Send(reply)

This has the benefit of allowing slow lookups/processing to happen against = 0-RTT, while delaying the "risky actions" until after 1-RTT. If I= 'm not mistaken, it would also make timing attacks harder since any cache m= isses would be at least partly masked by the time required for the 1-RTT handshake.

Dual streams seems to just add complexity here. What I really care about as= a developer is whether I can fully trust the 0-RTT data, which is determin= ed by whether the handshake is finished.

Cheers,

Tim
--
Tim Jackson

Senior Product Security Architect, MobileIron Inc.


From: "Martin Thomson" <martin.thomson@gmail.com>
Date: Thursday, June 15, 2017 at 5:16:29 PM
To: "David Benjamin" <davidben@chromium.org>
Cc: "tls@ietf.org" <tls= @ietf.org>
Subject: Re: [TLS] Separate APIs for 0-RTT

On 15 June 2017 at 08:23, David Benjamin <david= ben@chromium.org> wrote:
> When accepting 0-RTT as a server, a TLS implementation SHOULD/MUST pro= vide a
> way for the application to determine if the client Finished has been > processed.


I'm going to throw my support behind this distinction.  Though I would=
phrase this more simply as "the handshake is complete".

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls
 --_000_bi1n55pr8mut29311935117k1498183830709emailandroidcom_-- From nobody Thu Jun 22 19:31:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 861D91242EA for ; Thu, 22 Jun 2017 19:31:03 -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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 v9Nl9mS4R4Fs for ; Thu, 22 Jun 2017 19:31:01 -0700 (PDT) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 E7520120724 for ; Thu, 22 Jun 2017 19:31:01 -0700 (PDT) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5N2R7Co032652; Fri, 23 Jun 2017 03:30:59 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=OgkBFL+v9IXmZunQbv1cFAKNNxCqCfYV/MNlW4PAp2A=; b=ko9daecJEXH4r8AyciZfCxN+9sWjteCzRo3u6HiNjvfUb7vQXgpxlpKgKNl81gAvQ+HU rNsEYDmAwXR1dIKB1vkvRCAvUO7Ys+dBvzoifewpIaUIwNW3r+RwOzETBNmSiwCE7PUC rx5U3odWY4rGael9n1wwHUhxfZYoYxmec8k+WM14U85RtKvPcaG7pUEVlt1DOIoGe9AA BgKlpIE5Lewg9YzfJXu6LeJIZfHCTxngkat8xuf3vKOa486sTAMWSiltG4zFs1jC/L6z JZes+5vyjfHmd/Ej9gt+iln9UBMZlMweIank6qnvmwDoUm0ZFRp5MzfURC+0l+jXcYMp qw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2b8kpx24cr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 23 Jun 2017 03:30:59 +0100 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5N2PkL5012296; Thu, 22 Jun 2017 22:30:58 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2b4yrvf91r-1; Thu, 22 Jun 2017 22:30:58 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id BE74420064; Thu, 22 Jun 2017 20:30:57 -0600 (MDT) To: Timothy Jackson , Martin Thomson , David Benjamin Cc: "tls@ietf.org" References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> From: Benjamin Kaduk Message-ID: Date: Thu, 22 Jun 2017 21:30:57 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1D2A9AF36FED06447DE559E2" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230039 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-22_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706230040 Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2017 02:31:03 -0000 This is a multi-part message in MIME format. --------------1D2A9AF36FED06447DE559E2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 06/22/2017 09:10 PM, Timothy Jackson wrote: > +1 and a preference for MUST, just so people understand the importance. > > Since we're agreed that 0-RTT data and 1-RTT data have (almost) the > same security properties once the handshake completes, it seems to me, > unless I've missed something, that a lot of protocols will accept > 0-RTT but withhold the response until after the handshake completes. I > expect this massively simplifies the analysis the for the app developers. > > Clientdata = readData() > Reply = CreateReply(client data); //time intensive operation (e.g. > Database, CDN cache lookup) > > While(!clientFinished()) > Wait(); //do nothing until 1-RTT finished > > Send(reply) > > This has the benefit of allowing slow lookups/processing to happen > against 0-RTT, while delaying the "risky actions" until after 1-RTT. > If I'm not mistaken, it would also make timing This is still the server taking action on 0-RTT data before the handshake completes, using resources on potentially spoofed input. Caution is needed to not utilize excessive server resources in such cases. -Ben > attacks harder since any cache misses would be at least partly masked > by the time required for the 1-RTT handshake. > > Dual streams seems to just add complexity here. What I really care > about as a developer is whether I can fully trust the 0-RTT data, > which is determined by whether the handshake is finished. --------------1D2A9AF36FED06447DE559E2 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 06/22/2017 09:10 PM, Timothy Jackson wrote:
+1 and a preference for MUST, just so people understand the importance.

Since we're agreed that 0-RTT data and 1-RTT data have (almost) the same security properties once the handshake completes, it seems to me, unless I've missed something, that a lot of protocols will accept 0-RTT but withhold the response until after the handshake completes. I expect this massively simplifies the analysis the for the app developers.

Clientdata = readData()
Reply = CreateReply(client data); //time intensive operation (e.g. Database, CDN cache lookup)

While(!clientFinished())
Wait(); //do nothing until 1-RTT finished

Send(reply)

This has the benefit of allowing slow lookups/processing to happen against 0-RTT, while delaying the "risky actions" until after 1-RTT. If I'm not mistaken, it would also make timing

This is still the server taking action on 0-RTT data before the handshake completes, using resources on potentially spoofed input. Caution is needed to not utilize excessive server resources in such cases.

-Ben

attacks harder since any cache misses would be at least partly masked by the time required for the 1-RTT handshake.

Dual streams seems to just add complexity here. What I really care about as a developer is whether I can fully trust the 0-RTT data, which is determined by whether the handshake is finished.

--------------1D2A9AF36FED06447DE559E2-- From nobody Thu Jun 22 20:43:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4491241FC for ; Thu, 22 Jun 2017 20:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.998 X-Spam-Level: X-Spam-Status: No, score=-0.998 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_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ret_1Wo9i1Dl for ; Thu, 22 Jun 2017 20:43:44 -0700 (PDT) Received: from mail-wr0-x22b.google.com (mail-wr0-x22b.google.com [IPv6:2a00:1450:400c:c0c::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 0C355129463 for ; Thu, 22 Jun 2017 20:43:44 -0700 (PDT) Received: by mail-wr0-x22b.google.com with SMTP id k67so47751331wrc.2 for ; Thu, 22 Jun 2017 20:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=e/IaQ0+c4A0ZsiKt8biU4HlfrHAZmw3gka6mqxUb3iE=; b=mX2FFRE/rzQ+uAHrysyhoZHdxBzLgXFpv1Ey14BH0vb/GGJc36Gu2FfpUCNhHSPDoJ JtCbvms08dXoVTMXgrjlTdhJPJ8oxVEpjhgeQLG2MEGhXshDICEzigEKaVM0aR8rugiC wPTYVqsi8PJWojLsT3HJlvc5Di4OvvCsL5EYzzgg3au5l+i29ytO+eUILF7ptxMjHD57 yvbFea7EwRwFO0GKwqR2lxgCVTG9s1NiNKr5/ayPjAWPrJHJLoiFGJaz1PwKPLuNCsEl SGeHyXnPhUXghYyNiMjBa5i9PXzcu4ufGJ/otQKXSPfXVIUAkOBXTtosq2k2WhYOICRR GN6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=e/IaQ0+c4A0ZsiKt8biU4HlfrHAZmw3gka6mqxUb3iE=; b=W0MK9duPo0wUn9qwDTjuaFBgEpiQyS2GuFOA+RvC2kknHQb6Chy+dkjV5/LUZxXcWP 7oSQXb4g7+UW4R5oiX1GTQpXeBc/36QjimUhIF0uBak/KEmU7u9KScKxy9zUz8ETXunT KqFzHaCtOYZxxbMQDOcOTlN1RYPW6BvLYH7SYItXtAVVCB/mon2hLba1+Ot7i+4d6wbY gCTL4uQdwHy7jSWCpN2zpvcYTmy3FduarQbKvHtYrqSK3sh6szhrHKhkyLbmJLF+yKu2 YpINmkzsIzSKY4g6yCkWu2XED/1gqxvMQJABL11Z74Wrt+WsA5y6VuFdssDPhzVbCUYf sh/g== X-Gm-Message-State: AKS2vOwqZNuYZMBYlmj3Rezpa+UQYB+HDADyzHMFnhk8Kc4+bye8MCa8 aY/rrck2PiW7Rw== X-Received: by 10.80.147.79 with SMTP id n15mr4584791eda.84.1498189422559; Thu, 22 Jun 2017 20:43:42 -0700 (PDT) Received: from [192.168.1.18] ([46.120.57.147]) by smtp.gmail.com with ESMTPSA id g28sm2018709eda.58.2017.06.22.20.43.40 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jun 2017 20:43:41 -0700 (PDT) From: Yoav Nir Message-Id: <9A520B6A-D8DE-41FC-B732-5E1C6DFCD707@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_627B4EA3-A8BD-41CA-901D-64988DC838E7"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Fri, 23 Jun 2017 06:43:37 +0300 In-Reply-To: Cc: Martin Thomson , David Benjamin , "tls@ietf.org" To: Timothy Jackson References: <8e206c83-645f-6389-a7bd-ddd51e747ea2@akamai.com> <20170613183536.GA12760@LK-Perkele-V2.elisa-laajakaista.fi> <63c8ac33-489c-0ace-d4ba-b960cd965281@akamai.com> <20170613205530.GB13223@LK-Perkele-V2.elisa-laajakaista.fi> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Separate APIs for 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2017 03:43:46 -0000 --Apple-Mail=_627B4EA3-A8BD-41CA-901D-64988DC838E7 Content-Type: multipart/alternative; boundary="Apple-Mail=_19AAFA0F-E24B-4179-AC23-638199C616CE" --Apple-Mail=_19AAFA0F-E24B-4179-AC23-638199C616CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 23 Jun 2017, at 5:10, Timothy Jackson = wrote: >=20 > +1 and a preference for MUST, just so people understand the = importance. >=20 > Since we're agreed that 0-RTT data and 1-RTT data have (almost) the = same security properties once the handshake completes, it seems to me, = unless I've missed something, that a lot of protocols will accept 0-RTT = but withhold the response until after the handshake completes. I expect = this massively simplifies the analysis the for the app developers. >=20 > Clientdata =3D readData() > Reply =3D CreateReply(client data); //time intensive operation (e.g. = Database, CDN cache lookup) >=20 > While(!clientFinished()) > Wait(); //do nothing until 1-RTT finished >=20 > Send(reply) This assumes that CreateReply() has no side effects. It=E2=80=99s valid = as long as all actions done by the server in response to the client data = is getting stuff from a database. >=20 > This has the benefit of allowing slow lookups/processing to happen = against 0-RTT, while delaying the "risky actions" until after 1-RTT. If = I'm not mistaken, it would also make timing attacks harder since any = cache misses would be at least partly masked by the time required for = the 1-RTT handshake. >=20 > Dual streams seems to just add complexity here. What I really care = about as a developer is whether I can fully trust the 0-RTT data, which = is determined by whether the handshake is finished. >=20 > Cheers, >=20 > Tim > -- > Tim Jackson >=20 > Senior Product Security Architect, MobileIron Inc. >=20 >=20 > From: "Martin Thomson" > > Date: Thursday, June 15, 2017 at 5:16:29 PM > To: "David Benjamin" > > Cc: "tls@ietf.org" > > Subject: Re: [TLS] Separate APIs for 0-RTT >=20 > On 15 June 2017 at 08:23, David Benjamin = wrote: > > When accepting 0-RTT as a server, a TLS implementation SHOULD/MUST = provide a > > way for the application to determine if the client Finished has been > > processed. >=20 >=20 > I'm going to throw my support behind this distinction. Though I would > phrase this more simply as "the handshake is complete". >=20 > _______________________________________________ > 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 = --Apple-Mail=_19AAFA0F-E24B-4179-AC23-638199C616CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 23 Jun 2017, at 5:10, Timothy Jackson <tjackson@mobileiron.com> wrote:

+1 and a preference for MUST, just so = people understand the importance. 

Since we're agreed that 0-RTT data and 1-RTT data have = (almost) the same security properties once the handshake completes, it = seems to me, unless I've missed something, that a lot of protocols will = accept 0-RTT but withhold the response until after the handshake = completes. I expect this massively simplifies the analysis the for the = app developers. 

Clientdata =3D readData()
Reply = =3D CreateReply(client data); //time intensive operation (e.g. Database, = CDN cache lookup)

While(!clientFinished())Wait(); //do nothing until 1-RTT finished

Send(reply)

This = assumes that CreateReply() has no side effects. It=E2=80=99s valid as = long as all actions done by the server in response to the client data is = getting stuff from a database. 


This has the benefit of allowing slow = lookups/processing to happen against 0-RTT, while delaying the "risky = actions" until after 1-RTT. If I'm not mistaken, it would also make = timing attacks harder since any cache misses would be at least partly = masked by the time required for the 1-RTT handshake. 

Dual streams seems to just add complexity here. What I really = care about as a developer is whether I can fully trust the 0-RTT data, = which is determined by whether the handshake is finished. 

Cheers,

Tim
--
Tim Jackson

Senior Product = Security Architect, MobileIron Inc. 


From: "Martin Thomson" <martin.thomson@gmail.com>
Date: Thursday, June 15, 2017 at = 5:16:29 PM
To: "David Benjamin" <davidben@chromium.org>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Separate APIs for = 0-RTT

On 15 = June 2017 at 08:23, David Benjamin <davidben@chromium.org> wrote:
> When = accepting 0-RTT as a server, a TLS implementation SHOULD/MUST provide = a
> way for the application to determine if the client = Finished has been
> processed.


I'm going to throw my support behind this = distinction.  Though I would
phrase this more simply = as "the handshake is complete".

_______________________________________________
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

= --Apple-Mail=_19AAFA0F-E24B-4179-AC23-638199C616CE-- --Apple-Mail=_627B4EA3-A8BD-41CA-901D-64988DC838E7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQEcBAEBCgAGBQJZTI5qAAoJELhJCxUKWMyZSK4IAIyO0/xN4B2JVDAmATGuoWhh DBugJNkb9pfxUfqlRz27WXSmMwoXw5nJnNWRpHGEGOVlmwsk0PRz39TL0BnOzhNW 8gKosjUZ4t8l96rgDjhNijBIqXjbmDV4hIzrdVpelRbWyBmp74rvWCZMg9thcdzA 7jei2o5oGz0tXWZErjlXR/SpUhKSpig4jdFybSQCY1zQv5pa2lMJ4oaTppFsTFJS gYk4SOO130PRpahxJV8bN0LW/eqplQJ7ionLIkLEpJ//dRRocAcx5PtJ1/GYrW4h 5EBHcV4afyxNopg4IbJ6YFTzcpHiyFlYq2GwlOu0Lhd9ct+5F1bBgiyHQOEo2ug= =u56e -----END PGP SIGNATURE----- --Apple-Mail=_627B4EA3-A8BD-41CA-901D-64988DC838E7-- From nobody Fri Jun 23 09:22:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60E351200B9 for ; Fri, 23 Jun 2017 09:22:07 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 purwPnxlwKh5 for ; Fri, 23 Jun 2017 09:22:04 -0700 (PDT) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::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 691141289B0 for ; Fri, 23 Jun 2017 09:22:03 -0700 (PDT) Received: by mail-pf0-x230.google.com with SMTP id q86so25542748pfl.3 for ; Fri, 23 Jun 2017 09:22:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ezwHF5/ywrEGyQyNj85pPZchYATSV7BllqlCaEZ2E2c=; b=IMSRVy6ytfO1kCfmdoQAMYR9EUW3HRESMtECRG6so/78D0CHJ2WY7QvL3hEk3RXb7I SVNt1u8BAQf1peQQFZzy6xlt89PZvyKssnEfEGQ9Zy+NLKxStniW13DefEXuVsmKCN9G gdiNtQbCccz5yGl4IHpScqa9Wtzau/3htkQCZF2QeZfpO+B5lHd/yz4fceVFMA5o44LH Lcd3Muxlq1omW82KXZbDf2kbbS1JtbYsV1UKhxTDX3iUJK8xtrT1QZDC7MvdBCc7sdsW nRikPz9AWpHRExRC4puxKfYPby+W1GDA1slcG30uztfnZsq7Icb09JWo1FBzunh7FG6g kakQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ezwHF5/ywrEGyQyNj85pPZchYATSV7BllqlCaEZ2E2c=; b=TeSXTr1LEIBS82uoOrQt7KQIE441DRVaBYfw4k+LzGYuuy9MhRCpRZslakraunGZwp 8HvOa6brHng/RcTCId+4suPERyGuAYuv9Vgoe/EzFYJqvoh/MrKhzi2f2UZZnX8+xHiw Hvib3NZkB8IHUqidz5EZwZMR028Ms4iF52zC9V0EnySj+IMdRDiTXhFKha1gtFYdDdeC 21lefDG7gZpo/UNbf22JDb8LqWVDc+/bL6evmwLdAynL+FG1C7Vw4M2h0iTJs/6IfEgn Oos4qg8V8cSPfYxs29aN7Gy0dEtfVJ/wNU3F2ktx3uBXY43P5F0RNSUzghICbR29TYAc +vCg== X-Gm-Message-State: AKS2vOzIsLeIbznizqCPfzwPH6upAQyTHnHT9AaSwQjXi2K5osfhMR1v aPjwrA1YsQCn0H0FeQDFGhdU4gY2noxR X-Received: by 10.98.141.134 with SMTP id p6mr9122538pfk.68.1498234923004; Fri, 23 Jun 2017 09:22:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.176.233 with HTTP; Fri, 23 Jun 2017 09:21:42 -0700 (PDT) In-Reply-To: <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> From: Joseph Salowey Date: Fri, 23 Jun 2017 09:21:42 -0700 Message-ID: To: Eric Rescorla Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c0ecffa6055c70552a30011" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2017 16:22:07 -0000 --94eb2c0ecffa6055c70552a30011 Content-Type: text/plain; charset="UTF-8" Hi Ekr, Discussion on this topic is dying down, can you post a PR so we can see the proposed text. There is still some discussion on the API thread so there may be some additional modifications coming in that area. On Wed, Jun 14, 2017 at 10:45 AM, Ilari Liusvaara wrote: > On Tue, Jun 13, 2017 at 03:24:24PM -0700, Bill Cox wrote: > > On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> > > wrote: > > > > > > - Note that 0-RTT exporters are not safe for authentication on > servers > > > > that do not enforce single-use tickets, or for clients that do not > > > > recompute authentication signatures on retransmission of early data. > > > > > > "Single-use tickets" imply global anti-replay. > > > > > > > I assumed "gobal anti-replay" meant there would be a globally > synchronized > > cache of valid single-use tickets. It sounds like you mean "global > > anti-replay" includes schemes using orbit/metro/server bound tickets, > since > > they can support single-use tickets. In that case, I agree with you, > but I > > think the phrase "single-use tickets" may be less confusing. Maybe just > > say "anti-replay" instead of "global anti-replay"? > > IMO, "anti-replay" also includes per-server anti-replay, which archives > "at most N replays" in global scale. > > Of course, the ticket scope of server can be wider than the 0-RTT scope > (the server accepts tickets but rejects 0-RTT from any ticket in > between). > > > And the latter part is way too obscure. I have no idea how it is > > > trying to fix ClientHello replay resulting the same exporter > > > output. > > > > > > > I don't know what you mean by "resulting the same exporter output." Auth > > signatures in a 1-RTT fallback need to be recomputed using the 1-RTT > > exporter to avoid having the same signature accepted twice. Maybe this > is > > too specific and should be left out. > > If you replay ClientHello and it gets accepted twice, including to > different servers, both connections have the same 0-RTT exporter values. > > The 1-RTT exporter values will not be the same, but this is not helpful > for 0-RTT data, or for that matter any 1-RTT data unless exporters are > switched mid-stream. > > > > Even this is only partially true. Anti-replay can be built above the > TLS > > > > layer. I'm considering doing token-binding replay defense in the > > > > authentication backend, to help ensure the token-binding guarantee: > that > > > > auth tokens taken from one device cannot be used from another device > > > > without continued access to the first device's signing oracle. > > > > Unfortunately, 0-RTT master resumption secrets are a new kind of auth > > > > bearer token, and the token binding spec does not cover them. > > > > > > Doing stuff like this gets more and more complicated and fragile as > > > one moves up the layer stack. > > > > > > > It depends on the task. Moving channel ID from the TLS layer to token > > binding in the HTTP layer should simplify the TLS state machine enough to > > justify the change. > > Implementing such thing without some TLS support at application layer is > just crazy. > > IMO, the only reason token binding concerns itself at all with TLS is > that "0.5 RTT" (a TLS 1.3 feature) and HTTP/2 was not available when > token binding was started. Those (together with exporters) would have > enabled token binding in HTTPS without having to mess with TLS. > > (The messing with TLS in token binding seems to be solely about saving > round-trips!) > > > Anti-replay in the TLS layer would be good for 0-RTT > > token binding, but the cost and complexity of running the whole > user-facing > > fleet of servers with anti-replay caches is huge, many times higher than > > the cost of token-binding anti-replay in the backend. Also, the > > authentication backend is where bound tokens are currently verified, so > > putting the anti-replay there seems like the appropriate layer. > > That greatly depends on the implementation and deployment. That's why it > is more fragile. > > E.g. run more than one authentication backend for 0-RTT scope, and > your application layer anti-replay breaks. And I'm not convinced the > scale of anti-replay cache would be much smaller at application layer, in > fact, it could be even biger. > > > I'm still not sure this scheme is worth implementing, but without it, I > do > > not think we can support client certificates or token binding over 0-RTT. > > It doesn't really matter for the TLS 1.3 spec. I'm just pointing out > that > > the statement "0-RTT auth is insecure without anti-replay defense" is not > > 100% accurate. There are other ways to improve the security. > > Well, client certificates are currently forbidden for connections with > 0-RTT data (indirectly, but it is still forbidden). It could become > possible > in the future. > > > > > > -Ilari > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c0ecffa6055c70552a30011 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ekr,

Discussion on this topic is dyi= ng down, can you post a PR so we can see the proposed text.=C2=A0 There is = still some discussion on the API thread so there may be some additional mod= ifications coming in that area. =C2=A0


On Wed, Jun 14, 2017 at 10:= 45 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wro= te:
On Tue, Jun 13, 2017= at 03:24:24PM -0700, Bill Cox wrote:
> On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
> > >=C2=A0 =C2=A0- Note that 0-RTT exporters are not safe for aut= hentication on servers
> > > that do not enforce single-use tickets, or for clients that = do not
> > > recompute authentication signatures on retransmission of ear= ly data.
> >
> > "Single-use tickets" imply global anti-replay.
> >
>
> I assumed "gobal anti-replay" meant there would be a globall= y synchronized
> cache of valid single-use tickets.=C2=A0 It sounds like you mean "= ;global
> anti-replay" includes schemes using orbit/metro/server bound tick= ets, since
> they can support single-use tickets.=C2=A0 In that case, I agree with = you, but I
> think the phrase "single-use tickets" may be less confusing.= =C2=A0 Maybe just
> say "anti-replay" instead of "global anti-replay"?=

IMO, "anti-replay" also includes per-server anti-replay, w= hich archives
"at most N replays" in global scale.

Of course, the ticket scope of server can be wider than the 0-RTT scope
(the server accepts tickets but rejects 0-RTT from any ticket in
between).

> And the latter part is way too obscure. I have no idea how it is
> > trying to fix ClientHello replay resulting the same exporter
> > output.
> >
>
> I don't know what you mean by "resulting the same exporter ou= tput."=C2=A0 Auth
> signatures in a 1-RTT fallback need to be recomputed using the 1-RTT > exporter to avoid having the same signature accepted twice.=C2=A0 Mayb= e this is
> too specific and should be left out.

If you replay ClientHello and it gets accepted twice, including to different servers, both connections have the same 0-RTT exporter values.
The 1-RTT exporter values will not be the same, but this is not helpful
for 0-RTT data, or for that matter any 1-RTT data unless exporters are
switched mid-stream.

> > Even this is only partially true.=C2=A0 Anti-replay can be built = above the TLS
> > > layer.=C2=A0 I'm considering doing token-binding replay = defense in the
> > > authentication backend, to help ensure the token-binding gua= rantee: that
> > > auth tokens taken from one device cannot be used from anothe= r device
> > > without continued access to the first device's signing o= racle.
> > > Unfortunately, 0-RTT master resumption secrets are a new kin= d of auth
> > > bearer token, and the token binding spec does not cover them= .
> >
> > Doing stuff like this gets more and more complicated and fragile = as
> > one moves up the layer stack.
> >
>
> It depends on the task.=C2=A0 Moving channel ID from the TLS layer to = token
> binding in the HTTP layer should simplify the TLS state machine enough= to
> justify the change.

Implementing such thing without some TLS support at application laye= r is
just crazy.

IMO, the only reason token binding concerns itself at all with TLS is
that "0.5 RTT" (a TLS 1.3 feature) and HTTP/2 was not available w= hen
token binding was started. Those (together with exporters) would have
enabled token binding in HTTPS without having to mess with TLS.

(The messing with TLS in token binding seems to be solely about saving
round-trips!)

> Anti-replay in the TLS layer would be good for 0-RTT
> token binding, but the cost and complexity of running the whole user-f= acing
> fleet of servers with anti-replay caches is huge, many times higher th= an
> the cost of token-binding anti-replay in the backend.=C2=A0 Also, the<= br> > authentication backend is where bound tokens are currently verified, s= o
> putting the anti-replay there seems like the appropriate layer.

That greatly depends on the implementation and deployment. That'= s why it
is more fragile.

E.g. run more than one authentication backend for 0-RTT scope, and
your application layer anti-replay breaks. And I'm not convinced the scale of anti-replay cache would be much smaller at application layer, in fact, it could be even biger.

> I'm still not sure this scheme is worth implementing, but without = it, I do
> not think we can support client certificates or token binding over 0-R= TT.
> It doesn't really matter for the TLS 1.3 spec.=C2=A0 I'm just = pointing out that
> the statement "0-RTT auth is insecure without anti-replay defense= " is not
> 100% accurate.=C2=A0 There are other ways to improve the security.

Well, client certificates are currently forbidden for connections wi= th
0-RTT data (indirectly, but it is still forbidden). It could become possibl= e
in the future.





-Ilari

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

--94eb2c0ecffa6055c70552a30011-- From nobody Fri Jun 23 10:44:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B20127333 for ; Fri, 23 Jun 2017 10:44:44 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 f-DMh-5SBjy8 for ; Fri, 23 Jun 2017 10:44:42 -0700 (PDT) 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 C5AA5126DCA for ; Fri, 23 Jun 2017 10:44:41 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id v7so19646459ywc.2 for ; Fri, 23 Jun 2017 10:44:41 -0700 (PDT) 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=+GNhYEM2NnOfwVOqa6tbNu2AEIXPm4RKs6Y0CJFzHcM=; b=N9zYXsZqUIrxZSbS41UEieRyB2ZoOoqBVkINET+R2TWyj//YIQsDkke1Y7ID9SN5cy 2A3h3i0mQHgMC8lsc77IuVfn7PIayU8+/PMyCbcPXyjyTlu6MlAid6pLzfG7EkLwiFSB L201wFlZAESN9KfpQstzI/EchSfHAAN7Stx3u27+1V6v5EBMWKzFX+8BRSZN0e4/SeFs Ek43okPVtgC+OGik1jKcquNwxCFzYcj3k8QfReLsqbeg49B5x4LiMSBlOSMZ+LJzAh/h aoFOWxuZOiJvLIK02vlfGA4iKQa1ujBPkTboEk1sj7fGjo9Jm3NO8WFL4H6kLZRDV2xY Co3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=+GNhYEM2NnOfwVOqa6tbNu2AEIXPm4RKs6Y0CJFzHcM=; b=Qc4psA0TyGlUycOdZgUldPlhIq0ngWsoJTn6+95n1+6+5NwtHXbOKGBccYNRwof2xZ ARMrnZbqJT7Nk9EdHiybuLL6qy+XMWPN6gnxBb07jR30HTNpAeFEthqc2FodCJ5dT0Fu iCLY1ISEqusk1OJbKZ797FFAh07dmcMqH2wjiLth/lzCGrifLX0HxVx3VU7iW/3/VuEq 6igghoSJoY6u0PaVGMaoai71Q2RT+iOfTLKkj2cEPjSKH2QfYM3Le4w3HCk1oKYSvQh1 6e2s4YnTlOzF8cje2WJ+vH0bbiNxf2REJ/vijv4qt6j5oCeiwZxdSNHfKhoQRsofPQAz DXog== X-Gm-Message-State: AKS2vOwgDCybls1aymU+RM1pOP+36m6UVwiMvVPu6zaSI+QEpD/nbTUS CGV+q0BrryIzMtnWhPl9cA+duNIKEe+hfz3Uqg== X-Received: by 10.129.109.17 with SMTP id i17mr7070656ywc.3.1498239880938; Fri, 23 Jun 2017 10:44:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Fri, 23 Jun 2017 10:44:00 -0700 (PDT) In-Reply-To: References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> From: Eric Rescorla Date: Fri, 23 Jun 2017 10:44:00 -0700 Message-ID: To: Joseph Salowey Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114dd50ee480b60552a4271f" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 23 Jun 2017 17:44:45 -0000 --001a114dd50ee480b60552a4271f Content-Type: text/plain; charset="UTF-8" PR up: https://github.com/tlswg/tls13-spec/pull/1034 On Fri, Jun 23, 2017 at 9:21 AM, Joseph Salowey wrote: > Hi Ekr, > > Discussion on this topic is dying down, can you post a PR so we can see > the proposed text. There is still some discussion on the API thread so > there may be some additional modifications coming in that area. > > > On Wed, Jun 14, 2017 at 10:45 AM, Ilari Liusvaara < > ilariliusvaara@welho.com> wrote: > >> On Tue, Jun 13, 2017 at 03:24:24PM -0700, Bill Cox wrote: >> > On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara < >> ilariliusvaara@welho.com> >> > wrote: >> > >> > > > - Note that 0-RTT exporters are not safe for authentication on >> servers >> > > > that do not enforce single-use tickets, or for clients that do not >> > > > recompute authentication signatures on retransmission of early data. >> > > >> > > "Single-use tickets" imply global anti-replay. >> > > >> > >> > I assumed "gobal anti-replay" meant there would be a globally >> synchronized >> > cache of valid single-use tickets. It sounds like you mean "global >> > anti-replay" includes schemes using orbit/metro/server bound tickets, >> since >> > they can support single-use tickets. In that case, I agree with you, >> but I >> > think the phrase "single-use tickets" may be less confusing. Maybe just >> > say "anti-replay" instead of "global anti-replay"? >> >> IMO, "anti-replay" also includes per-server anti-replay, which archives >> "at most N replays" in global scale. >> >> Of course, the ticket scope of server can be wider than the 0-RTT scope >> (the server accepts tickets but rejects 0-RTT from any ticket in >> between). >> >> > And the latter part is way too obscure. I have no idea how it is >> > > trying to fix ClientHello replay resulting the same exporter >> > > output. >> > > >> > >> > I don't know what you mean by "resulting the same exporter output." >> Auth >> > signatures in a 1-RTT fallback need to be recomputed using the 1-RTT >> > exporter to avoid having the same signature accepted twice. Maybe this >> is >> > too specific and should be left out. >> >> If you replay ClientHello and it gets accepted twice, including to >> different servers, both connections have the same 0-RTT exporter values. >> >> The 1-RTT exporter values will not be the same, but this is not helpful >> for 0-RTT data, or for that matter any 1-RTT data unless exporters are >> switched mid-stream. >> >> > > Even this is only partially true. Anti-replay can be built above the >> TLS >> > > > layer. I'm considering doing token-binding replay defense in the >> > > > authentication backend, to help ensure the token-binding guarantee: >> that >> > > > auth tokens taken from one device cannot be used from another device >> > > > without continued access to the first device's signing oracle. >> > > > Unfortunately, 0-RTT master resumption secrets are a new kind of >> auth >> > > > bearer token, and the token binding spec does not cover them. >> > > >> > > Doing stuff like this gets more and more complicated and fragile as >> > > one moves up the layer stack. >> > > >> > >> > It depends on the task. Moving channel ID from the TLS layer to token >> > binding in the HTTP layer should simplify the TLS state machine enough >> to >> > justify the change. >> >> Implementing such thing without some TLS support at application layer is >> just crazy. >> >> IMO, the only reason token binding concerns itself at all with TLS is >> that "0.5 RTT" (a TLS 1.3 feature) and HTTP/2 was not available when >> token binding was started. Those (together with exporters) would have >> enabled token binding in HTTPS without having to mess with TLS. >> >> (The messing with TLS in token binding seems to be solely about saving >> round-trips!) >> >> > Anti-replay in the TLS layer would be good for 0-RTT >> > token binding, but the cost and complexity of running the whole >> user-facing >> > fleet of servers with anti-replay caches is huge, many times higher than >> > the cost of token-binding anti-replay in the backend. Also, the >> > authentication backend is where bound tokens are currently verified, so >> > putting the anti-replay there seems like the appropriate layer. >> >> That greatly depends on the implementation and deployment. That's why it >> is more fragile. >> >> E.g. run more than one authentication backend for 0-RTT scope, and >> your application layer anti-replay breaks. And I'm not convinced the >> scale of anti-replay cache would be much smaller at application layer, in >> fact, it could be even biger. >> >> > I'm still not sure this scheme is worth implementing, but without it, I >> do >> > not think we can support client certificates or token binding over >> 0-RTT. >> > It doesn't really matter for the TLS 1.3 spec. I'm just pointing out >> that >> > the statement "0-RTT auth is insecure without anti-replay defense" is >> not >> > 100% accurate. There are other ways to improve the security. >> >> Well, client certificates are currently forbidden for connections with >> 0-RTT data (indirectly, but it is still forbidden). It could become >> possible >> in the future. >> >> >> >> >> >> -Ilari >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > --001a114dd50ee480b60552a4271f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Fri, Jun 23, 2017 at 9:21 AM, Joseph Salowey <joe@salowey.net> wrote:
Hi = Ekr,

Discussion on this topic is dying down, can you pos= t a PR so we can see the proposed text.=C2=A0 There is still some discussio= n on the API thread so there may be some additional modifications coming in= that area. =C2=A0

On Tue, Jun 13, 2017 at 03:24:24PM -0700, Bill Cox wrote:
> On Tue, Jun 13, 2017 at 1:51 PM, Ilari Liusvaara <ilariliusvaara@welho.com&g= t;
> wrote:
>
> > >=C2=A0 =C2=A0- Note that 0-RTT exporters are not safe for aut= hentication on servers
> > > that do not enforce single-use tickets, or for clients that = do not
> > > recompute authentication signatures on retransmission of ear= ly data.
> >
> > "Single-use tickets" imply global anti-replay.
> >
>
> I assumed "gobal anti-replay" meant there would be a globall= y synchronized
> cache of valid single-use tickets.=C2=A0 It sounds like you mean "= ;global
> anti-replay" includes schemes using orbit/metro/server bound tick= ets, since
> they can support single-use tickets.=C2=A0 In that case, I agree with = you, but I
> think the phrase "single-use tickets" may be less confusing.= =C2=A0 Maybe just
> say "anti-replay" instead of "global anti-replay"?=

IMO, "anti-replay" also includes per-server anti-replay, w= hich archives
"at most N replays" in global scale.

Of course, the ticket scope of server can be wider than the 0-RTT scope
(the server accepts tickets but rejects 0-RTT from any ticket in
between).

> And the latter part is way too obscure. I have no idea how it is
> > trying to fix ClientHello replay resulting the same exporter
> > output.
> >
>
> I don't know what you mean by "resulting the same exporter ou= tput."=C2=A0 Auth
> signatures in a 1-RTT fallback need to be recomputed using the 1-RTT > exporter to avoid having the same signature accepted twice.=C2=A0 Mayb= e this is
> too specific and should be left out.

If you replay ClientHello and it gets accepted twice, including to different servers, both connections have the same 0-RTT exporter values.
The 1-RTT exporter values will not be the same, but this is not helpful
for 0-RTT data, or for that matter any 1-RTT data unless exporters are
switched mid-stream.

> > Even this is only partially true.=C2=A0 Anti-replay can be built = above the TLS
> > > layer.=C2=A0 I'm considering doing token-binding replay = defense in the
> > > authentication backend, to help ensure the token-binding gua= rantee: that
> > > auth tokens taken from one device cannot be used from anothe= r device
> > > without continued access to the first device's signing o= racle.
> > > Unfortunately, 0-RTT master resumption secrets are a new kin= d of auth
> > > bearer token, and the token binding spec does not cover them= .
> >
> > Doing stuff like this gets more and more complicated and fragile = as
> > one moves up the layer stack.
> >
>
> It depends on the task.=C2=A0 Moving channel ID from the TLS layer to = token
> binding in the HTTP layer should simplify the TLS state machine enough= to
> justify the change.

Implementing such thing without some TLS support at application laye= r is
just crazy.

IMO, the only reason token binding concerns itself at all with TLS is
that "0.5 RTT" (a TLS 1.3 feature) and HTTP/2 was not available w= hen
token binding was started. Those (together with exporters) would have
enabled token binding in HTTPS without having to mess with TLS.

(The messing with TLS in token binding seems to be solely about saving
round-trips!)

> Anti-replay in the TLS layer would be good for 0-RTT
> token binding, but the cost and complexity of running the whole user-f= acing
> fleet of servers with anti-replay caches is huge, many times higher th= an
> the cost of token-binding anti-replay in the backend.=C2=A0 Also, the<= br> > authentication backend is where bound tokens are currently verified, s= o
> putting the anti-replay there seems like the appropriate layer.

That greatly depends on the implementation and deployment. That'= s why it
is more fragile.

E.g. run more than one authentication backend for 0-RTT scope, and
your application layer anti-replay breaks. And I'm not convinced the scale of anti-replay cache would be much smaller at application layer, in fact, it could be even biger.

> I'm still not sure this scheme is worth implementing, but without = it, I do
> not think we can support client certificates or token binding over 0-R= TT.
> It doesn't really matter for the TLS 1.3 spec.=C2=A0 I'm just = pointing out that
> the statement "0-RTT auth is insecure without anti-replay defense= " is not
> 100% accurate.=C2=A0 There are other ways to improve the security.

Well, client certificates are currently forbidden for connections wi= th
0-RTT data (indirectly, but it is still forbidden). It could become possibl= e
in the future.





-Ilari

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


--001a114dd50ee480b60552a4271f-- From nobody Fri Jun 23 17:13:30 2017 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 F0B3712EB29; Fri, 23 Jun 2017 17:07:10 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: Kathleen.Moriarty.ietf@gmail.com, tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149826283097.7840.5919959948745699610.idtracker@ietfa.amsl.com> Date: Fri, 23 Jun 2017 17:07:10 -0700 Archived-At: Subject: [TLS] tls - Requested session has been scheduled for IETF 99 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 24 Jun 2017 00:07:11 -0000 Dear Joseph Salowey, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. tls Session 1 (2:30:00) Wednesday, Morning Session I 0930-1200 Room Name: Grand Hilton Ballroom size: 250 --------------------------------------------- Request Information: --------------------------------------------------------- Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: Joseph Salowey Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: curdle uta acme cfrg httpbis rtcweb saag stir tcpinc tokbind perc quic Second Priority: sacm oauth People who must be present: Eric Rescorla Stephen Farrell Sean Turner Joseph A. Salowey Kathleen Moriarty Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jun 23 22:27:38 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06E49129B9D for ; Fri, 23 Jun 2017 22:27:37 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 INxTYJYVVpiM for ; Fri, 23 Jun 2017 22:27:34 -0700 (PDT) Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 541D7129B79 for ; Fri, 23 Jun 2017 22:27:33 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id A297C23876; Sat, 24 Jun 2017 08:27:31 +0300 (EEST) 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 i96SD2gR1dnU; Sat, 24 Jun 2017 08:27:31 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 23B9827B; Sat, 24 Jun 2017 08:27:28 +0300 (EEST) Date: Sat, 24 Jun 2017 08:27:27 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: Joseph Salowey , "tls@ietf.org" Message-ID: <20170624052727.26n4spscu77nlnlw@LK-Perkele-VII> References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <20170614174531.GA17930@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: NeoMutt/20170306 (1.8.0) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 24 Jun 2017 05:27:37 -0000 On Fri, Jun 23, 2017 at 10:44:00AM -0700, Eric Rescorla wrote: > > On Fri, Jun 23, 2017 at 9:21 AM, Joseph Salowey wrote: > > > Discussion on this topic is dying down, can you post a PR so we can see > > the proposed text. There is still some discussion on the API thread so > > there may be some additional modifications coming in that area. > > > PR up: > https://github.com/tlswg/tls13-spec/pull/1034 I didn't see any mention of the cache probing attack. I.e., Leak data from 0-RTT requests (especially URLs) by first priming caches using 0-RTT replay and then probe the caches using normal requests. This attack can be viable even at low replay count, it isn't like the others that require very high number of replays. And in fact, it benefits from having numerious zones. E.g., CDNs that have multiple datacenters that accept 0-RTT tickets of each other seem vulernable to abusing this for discovering HTTP GET URLs in 0-RTT requests. -Ilari From nobody Sat Jun 24 07:05:55 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CE441273E2 for ; Sat, 24 Jun 2017 07:05:54 -0700 (PDT) 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 IWTTpM5t8xid for ; Sat, 24 Jun 2017 07:05:52 -0700 (PDT) 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 725FE126CC7 for ; Sat, 24 Jun 2017 07:05:52 -0700 (PDT) Received: by mail-yw0-x22b.google.com with SMTP id e142so25311961ywa.1 for ; Sat, 24 Jun 2017 07:05:52 -0700 (PDT) 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=0mjiic4m3UhvwwTY27M7kvdP9PO/CQjxynaQCfFwk0A=; b=GqYRjFILnBVDPPKW1FNEWaIzemc0TiYPXfL48BU4Eysk0I2n90w6t4/aRoyZod3wWw wGnWy4R4qRW96gsB5F4AAn1xk6qtKmgjIbS/10Uf094i5YV32wjUkEqF7Df9fVaweXyv OA4kdfOgXeBKRtlEHsVy/fjUE8U+Da3bjDD/wVUs8WTtQlKNlcMu81p/ZJ7FRDcedacE r9nIXWjcGQ7zVfnlr13gjNX4QMXBzUdo4zCsw8C6fIvMD4w2uxAE0/hwsO/Vy5aV2rU5 wNqVTg0JCwM9fn+YkCTSEHarjjGUCpTg71Up+b4dokH1qZ+v7ACwkOBpIPxVbheVW1Cs JQWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0mjiic4m3UhvwwTY27M7kvdP9PO/CQjxynaQCfFwk0A=; b=NgfhKecLvnSzmjwKHtnDG2MWqiUecfkpYLkn0vQ0MizOUaikcQkeDzX8B5RziqhJ/6 NJQgSxWRBkup/5E9EOe98MB16neod66oh4fZvqRlYl5yFAInPUkAtjN4QEm7Z6wE9/LU jlp3EZN/ZJFidh5A3XZAkpNUvv8najy70GtK3Oj5Z914yOkjT4uG9KMlqJbFqyQqp8f8 b7Vxh5pN4o4qLKLMvyCpdYVSSnHmT4wuaJhYXx39WpU7z9qkZSmetpYcu3AMqX2YaR8+ UmQaO7whlVfbX1gqIRu3LJTcUHi2QkAFKOr2mLaU3Pz2rbr1W6Y1JtV8r59XFKliW41s RpDA== X-Gm-Message-State: AKS2vOzNgumwYNTjj57PreVLHySVP8zsfjXuY68wLbJvA5mNym7sHQhw VDenmo3I4sEqm1tPe6ascyjIH6QxFeGaW0U= X-Received: by 10.13.252.194 with SMTP id m185mr9304102ywf.85.1498313151697; Sat, 24 Jun 2017 07:05:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 24 Jun 2017 07:05:11 -0700 (PDT) In-Reply-To: <20170624052727.26n4spscu77nlnlw@LK-Perkele-VII> References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> <20170624052727.26n4spscu77nlnlw@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 24 Jun 2017 07:05:11 -0700 Message-ID: To: Ilari Liusvaara Cc: Joseph Salowey , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c08d8102b92470552b53750" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 24 Jun 2017 14:05:54 -0000 --94eb2c08d8102b92470552b53750 Content-Type: text/plain; charset="UTF-8" i mentioned it here, but perhaps it's not clear enough. "If data can be replayed a large number of times, additional attacks become possible. Specifically, attackers can use multiple replays to exploit information leakage via side channels such as timing network caches or measuring the speed of cryptographic operations." I've got some other comments to resolve Monday I'll try to get to this then, but I'd also welcome suggested text on the PR. -Ekr On Fri, Jun 23, 2017 at 10:27 PM, Ilari Liusvaara wrote: > On Fri, Jun 23, 2017 at 10:44:00AM -0700, Eric Rescorla wrote: > > > > On Fri, Jun 23, 2017 at 9:21 AM, Joseph Salowey wrote: > > > > > Discussion on this topic is dying down, can you post a PR so we can see > > > the proposed text. There is still some discussion on the API thread so > > > there may be some additional modifications coming in that area. > > > > > PR up: > > https://github.com/tlswg/tls13-spec/pull/1034 > > I didn't see any mention of the cache probing attack. > > I.e., Leak data from 0-RTT requests (especially URLs) by first priming > caches using 0-RTT replay and then probe the caches using normal > requests. > > This attack can be viable even at low replay count, it isn't like the > others that require very high number of replays. And in fact, it > benefits from having numerious zones. > > > E.g., CDNs that have multiple datacenters that accept 0-RTT tickets of > each other seem vulernable to abusing this for discovering HTTP GET > URLs in 0-RTT requests. > > > -Ilari > --94eb2c08d8102b92470552b53750 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
i mentioned it here, but perhaps it's not clear e= nough.

"If data can be replayed a large numbe= r of times, additional attacks
become possible. Specifically,= attackers can use multiple replays to
exploit information leakag= e via side channels such as timing network
caches or measuring th= e speed of cryptographic operations."

I'v= e got some other comments to resolve Monday I'll try to get to this the= n,
but I'd also welcome suggested text on the PR.
<= br>
-Ekr


<= div class=3D"gmail_quote">On Fri, Jun 23, 2017 at 10:27 PM, Ilari Liusvaara= <ilariliusvaara@welho.com> wrote:
On Fri, Jun 23, 2017 at 10:44:00AM -0700, Eric Resc= orla wrote:
>
> On Fri, Jun 23, 2017 at 9:21 AM, Joseph Salowey <joe@salowey.net> wrote:
>
> > Discussion on this topic is dying down, can you post= a PR so we can see
> > the proposed text.=C2=A0 There is still some discussion on the AP= I thread so
> > there may be some additional modifications coming in that area. > >
> PR up:
> https://github.com/tlswg/tls13-spec/pull/1034=

I didn't see any mention of the cache probing attack.

I.e., Leak data from 0-RTT requests (especially URLs) by first priming
caches using 0-RTT replay and then probe the caches using normal
requests.

This attack can be viable even at low replay count, it isn't like the others that require very high number of replays. And in fact, it
benefits from having numerious zones.


E.g., CDNs that have multiple datacenters that accept 0-RTT tickets of
each other seem vulernable to abusing this for discovering HTTP GET
URLs in 0-RTT requests.


-Ilari

--94eb2c08d8102b92470552b53750-- From nobody Sat Jun 24 07:58:05 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E421273B1 for ; Sat, 24 Jun 2017 07:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.918 X-Spam-Level: X-Spam-Status: No, score=-0.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no 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 vInfgwXe8raL for ; Sat, 24 Jun 2017 07:58:02 -0700 (PDT) Received: from mail-yb0-x231.google.com (mail-yb0-x231.google.com [IPv6:2607:f8b0:4002: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 6CE03126D45 for ; Sat, 24 Jun 2017 07:58:02 -0700 (PDT) Received: by mail-yb0-x231.google.com with SMTP id e201so19802721ybb.1 for ; Sat, 24 Jun 2017 07:58:02 -0700 (PDT) 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=rNDS7hQZh2BPN3WF5woxA947lmMzXXLxhajKrM+NmkA=; b=iCeEZ9jpkB29ceH7SwceVO2kWkH+CEQlM2iXt1bHoYigyllFdi8ugG892FkIyxUVUC 9T9wROkhoOMaXMgJXNW7G/XA4XGl5DHu5kkzV+dhOkrUkA7EMpWsG7b7+40zfpVJti1t DkRGxIp7WyE7HdSCe2zYC63Yr9ROIEIY2hRZf8CLv08AJtbvEsdquxB+7zAexaZg21+f +eKWiETksbEfRsZG1U4abEm6+TG0URaeA4Hrg5U5+N3NKpynmBUdVQNNXEgblXiDIVAi Ntam2r+NPsT2veC3DAz3QK3TzsDsCBx0vcCPNG26W/eg39q9dUz3KpR2SQFKHDJmEXm4 Uztg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=rNDS7hQZh2BPN3WF5woxA947lmMzXXLxhajKrM+NmkA=; b=OkLeyfYk4qMY7iIVXaitmL7h2ahrnBqmxdGiEEtFBFb2H09yR6Slcojf6cnoLN/QHp ninmCnegOK3Rh9AtwNK+FpSt9OldSlEM+ei66KthChMcbuB3V0kdMWNPLw8sT9ATinue vq3LZ8scAdTVZykASjAVlOZzTIcxDyCcrWEBUN6heOeo8tmQVjgcnFAGiblFEAhJYt82 TIX+l3QJLKgiByC/wcINBCnKrizXj9FMNckYnm0lg896FWQ68LwjK/ufTCCSpHN2GBVL z8ot5OZz4qNJOH6wYuic+0C0Jd4l2nxyVB1y88bboVX+IFGE/N+wuvPlQgBsMmtBAtLq 2VxA== X-Gm-Message-State: AKS2vOxQKO277kUky9TMwtFHIo4EAx8EN3yFApkdV9D6hqVVz+7o4sLQ vSCufGWCh1Etkq+SCVl97gbhaBKOC4a/Ndjp9A== X-Received: by 10.37.118.210 with SMTP id r201mr9897131ybc.15.1498316281530; Sat, 24 Jun 2017 07:58:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 24 Jun 2017 07:57:21 -0700 (PDT) From: Eric Rescorla Date: Sat, 24 Jun 2017 07:57:21 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114bd4c8b8eb710552b5f1b4" Archived-At: Subject: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 24 Jun 2017 14:58:04 -0000 --001a114bd4c8b8eb710552b5f1b4 Content-Type: text/plain; charset="UTF-8" Hi folks, https://github.com/tlswg/dtls13-spec/pull/9 I have just posted a PR to implement ACKs, largely as we discussed in Chicago. Here's the pull comment: I have taken a slightly different approach here than we discussed in Chicago. Specifically: - ACKs are not handshake messages but a new content type. This avoids the need to ack ACKs or worry about reassembling when ACKs are lost. - The receipt of a flight also counts as an implicit ACK and so you shouldn't ACK full flights. I tried removing this feature but it leads to weird anomalies where you have two flights you should be retransmitting if the ACKs get lost. - ACKs are always encrypted with the then-current key. - I also removed the rule that you don't stop retransmitting when you receive a partial flight. That was intended to have fast retransmission for missing messages because the retransmit of flight A triggered retransmission of partial flight B, but ACKs serve this purpose Comments welcome. -Ekr --001a114bd4c8b8eb710552b5f1b4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi folks,


I have just posted a PR to implement AC= Ks, largely as we discussed in Chicago.
Here's the pull comme= nt:

I have taken = a slightly different approach here than we discussed
in Chicago. Specifically:

  • ACKs are not= handshake messages but a new content type. This
    avoids the need to ack ACKs or worry about reassembling
    when ACKs are lost.

  • The receipt of a flight also co= unts as an implicit ACK and
    so you shoul= dn't ACK full flights. I tried removing this
    feature but it leads to weird anomalies where you have
    two flights you should be retransmitting if the ACK= s get
    lost.

  • ACKs are always encrypted with = the then-current key.

  • I also removed the rule that you don't stop retransm= itting
    when you receive a partial flight= . That was intended to have
    fast retrans= mission for missing messages because the retransmit
    of flight A triggered retransmission of partial flight B, butACKs serve this purpose

Comments welcome.

-Ekr


--001a114bd4c8b8eb710552b5f1b4-- From nobody Sat Jun 24 09:47:58 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05F371243FE for ; Sat, 24 Jun 2017 09:47:57 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 ykCDPAjVx8v2 for ; Sat, 24 Jun 2017 09:47:54 -0700 (PDT) Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 2B88C1200FC for ; Sat, 24 Jun 2017 09:47:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id CF8EC25355; Sat, 24 Jun 2017 19:47:51 +0300 (EEST) 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 6QXwQdyrI8rG; Sat, 24 Jun 2017 19:47:51 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 4BB7E21C; Sat, 24 Jun 2017 19:47:49 +0300 (EEST) Date: Sat, 24 Jun 2017 19:47:49 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170306 (1.8.0) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 24 Jun 2017 16:47:57 -0000 On Sat, Jun 24, 2017 at 07:57:21AM -0700, Eric Rescorla wrote: > Hi folks, > > https://github.com/tlswg/dtls13-spec/pull/9 > > I have just posted a PR to implement ACKs, largely as we discussed in > Chicago. > Here's the pull comment: > > I have taken a slightly different approach here than we discussed > in Chicago. Specifically: > > - > > ACKs are not handshake messages but a new content type. This > avoids the need to ack ACKs or worry about reassembling > when ACKs are lost. > - > > The receipt of a flight also counts as an implicit ACK and > so you shouldn't ACK full flights. I tried removing this > feature but it leads to weird anomalies where you have > two flights you should be retransmitting if the ACKs get > lost. > - > > ACKs are always encrypted with the then-current key. > - > > I also removed the rule that you don't stop retransmitting > when you receive a partial flight. That was intended to have > fast retransmission for missing messages because the retransmit > of flight A triggered retransmission of partial flight B, but > ACKs serve this purpose > > Comments welcome. I think ACKing a post-handshake CertificateRequest would make sense, if the response can't be generated immediately (e.g., prompting user to select a certificate). It seems ACKs work in terms of RSNs. This generates a weirdness that a fragment can be known with multiple IDs, in case a packet gets delayed enough to trigger retransmission but the original is then accepted. But OTOH, retransmission at fragment granularity is useful with potentially "obese" messages like Certificate. And what is the precise interaction between restarts, 0-RTT and message sequence numbers on client side? As far as I can tell, end_of_early_data is always client message_seq=1, and appears only iff server accepts 0-RTT. Restart client_hello is also always client message_sseq=1. -Ilari From nobody Sat Jun 24 12:06:30 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C1F1127ABE for ; Sat, 24 Jun 2017 12:06:28 -0700 (PDT) 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 TErOb-nrCJEA for ; Sat, 24 Jun 2017 12:06:26 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002: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 37A581271DF for ; Sat, 24 Jun 2017 12:06:26 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id s9so20499046ybe.3 for ; Sat, 24 Jun 2017 12:06:26 -0700 (PDT) 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=iN1ynxMLqeOszajelO1d8pBC1c9X5v4eaaFGK1RL5CA=; b=szKtckx9yypbykcszZNn9d2SnWuE0Xl9EgVLGHGz4SR4HAhvb7GLhvuYWTSVuGlMfq PY1f1GuioI4d5BZESrl2JRWJt9AGtETbg1pxl5slxYYv+rl1j3YMghUi5pgar0k/0UQO H00PlWIVZY3Q7xgoB8s7/Y3pzzLfwQbZuEPzlL1fcsoTGKK47ZL67KpbW7XQ7oOfGOw9 pauw8yghOk4Zj0rHsKYPUk7oVUo07mnmQ+N6wNzSENmGchLCLfdAyKaeHrWYf+2TPYbc nx7MVVizQ3Ba9vHck/5YSSdhkdq6ANbNiEYJl1yodF18r3AL7jpf1h187I33e2dkBt2j XZ9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=iN1ynxMLqeOszajelO1d8pBC1c9X5v4eaaFGK1RL5CA=; b=FVfOGIDP79NUBBLPYuTzM0jwOpFv8RBAql0GHZmHhY8lDVMEVtT/mrYfyvQM7G4HUl WVmNJ2Cm4gCjESDQQKuo3K5i6jp8QzRdHv6k5ZkrTZ2xsU4+ARxstM+xd5JEkOE1naW4 awe0O27MaFKF1Mm1GbXoYcms5T7Q5JqYokf6OdbLS/tVxMgrViIeYPnMMdW+yvQMRxx7 dn1HVjh7PmivX3fhwa0txBXKFU/SSK6VlaEL2HvfQ1LTgkds1MTerMOIp0F73nBgg1Wg 0NLEzh0z0hc0zv0AqkaEgq7VYpjPJbQyF5VgTG0pm6USALhmY5Y3v8wsaVPJvfZ3aYjT HaIw== X-Gm-Message-State: AKS2vOz3nCWJ8pGvamGHdryj6fj/4rqGcvS2pKF1sVcAPAjXHJaTAGI1 +kcCF4Odk+dMfSA/p66EBKqbtrjmhwol X-Received: by 10.37.214.12 with SMTP id n12mr10558470ybg.122.1498331185335; Sat, 24 Jun 2017 12:06:25 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sat, 24 Jun 2017 12:05:44 -0700 (PDT) In-Reply-To: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> References: <20170624164749.bidmu2btsb6xsdjb@LK-Perkele-VII> From: Eric Rescorla Date: Sat, 24 Jun 2017 12:05:44 -0700 Message-ID: To: Ilari Liusvaara Cc: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114fcb700ee88f0552b96a05" Archived-At: Subject: Re: [TLS] DTLS 1.3 ACKs X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 24 Jun 2017 19:06:29 -0000 --001a114fcb700ee88f0552b96a05 Content-Type: text/plain; charset="UTF-8" On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara wrote: > On Sat, Jun 24, 2017 at 07:57:21AM -0700, Eric Rescorla wrote: > > Hi folks, > > > > https://github.com/tlswg/dtls13-spec/pull/9 > > > > I have just posted a PR to implement ACKs, largely as we discussed in > > Chicago. > > Here's the pull comment: > > > > I have taken a slightly different approach here than we discussed > > in Chicago. Specifically: > > > > - > > > > ACKs are not handshake messages but a new content type. This > > avoids the need to ack ACKs or worry about reassembling > > when ACKs are lost. > > - > > > > The receipt of a flight also counts as an implicit ACK and > > so you shouldn't ACK full flights. I tried removing this > > feature but it leads to weird anomalies where you have > > two flights you should be retransmitting if the ACKs get > > lost. > > - > > > > ACKs are always encrypted with the then-current key. > > - > > > > I also removed the rule that you don't stop retransmitting > > when you receive a partial flight. That was intended to have > > fast retransmission for missing messages because the retransmit > > of flight A triggered retransmission of partial flight B, but > > ACKs serve this purpose > > > > Comments welcome. > > I think ACKing a post-handshake CertificateRequest would make sense, if > the response can't be generated immediately (e.g., prompting user to > select a certificate). > That's a good point. It seems ACKs work in terms of RSNs. This generates a weirdness that > a fragment can be known with multiple IDs, in case a packet gets > delayed enough to trigger retransmission but the original is then > accepted. But OTOH, retransmission at fragment granularity is useful > with potentially "obese" messages like Certificate. > This is the calculation I made as well. Note that removing aliasing in this fashion actually is useful in measuring packet loss (this is what QUIC does). > And what is the precise interaction between restarts, 0-RTT and message > sequence numbers on client side? As far as I can tell, > end_of_early_data is always client message_seq=1, and appears only iff > server accepts 0-RTT. Restart client_hello is also always client > message_sseq=1. > That seems correct to me. -Ekr --001a114fcb700ee88f0552b96a05 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sat, Jun 24, 2017 at 9:47 AM, Ilari Liusvaara <= ilariliusvaar= a@welho.com> wrote:
On Sat, Jun 24, 2017 at 07:57:21AM -0700, Eric Rescorla wrote: > Hi folks,
>
> https://github.com/tlswg/dtls13-spec/pull/9=
>
> I have just posted a PR to implement ACKs, largely as we discussed in<= br> > Chicago.
> Here's the pull comment:
>
> I have taken a slightly different approach here than we discussed
> in Chicago. Specifically:
>
>=C2=A0 =C2=A0 -
>
>=C2=A0 =C2=A0 ACKs are not handshake messages but a new content type. T= his
>=C2=A0 =C2=A0 avoids the need to ack ACKs or worry about reassembling >=C2=A0 =C2=A0 when ACKs are lost.
>=C2=A0 =C2=A0 -
>
>=C2=A0 =C2=A0 The receipt of a flight also counts as an implicit ACK an= d
>=C2=A0 =C2=A0 so you shouldn't ACK full flights. I tried removing t= his
>=C2=A0 =C2=A0 feature but it leads to weird anomalies where you have >=C2=A0 =C2=A0 two flights you should be retransmitting if the ACKs get<= br> >=C2=A0 =C2=A0 lost.
>=C2=A0 =C2=A0 -
>
>=C2=A0 =C2=A0 ACKs are always encrypted with the then-current key.
>=C2=A0 =C2=A0 -
>
>=C2=A0 =C2=A0 I also removed the rule that you don't stop retransmi= tting
>=C2=A0 =C2=A0 when you receive a partial flight. That was intended to h= ave
>=C2=A0 =C2=A0 fast retransmission for missing messages because the retr= ansmit
>=C2=A0 =C2=A0 of flight A triggered retransmission of partial flight B,= but
>=C2=A0 =C2=A0 ACKs serve this purpose
>
> Comments welcome.

I think ACKing a post-handshake CertificateRequest would make sense,= if
the response can't be generated immediately (e.g., prompting user to select a certificate).

That's a goo= d point.


It seems ACKs work in terms of RSNs. This generates a weirdness that
a fragment can be known with multiple IDs, in case a packet gets
delayed enough to trigger retransmission but the original is then
accepted. But OTOH, retransmission at fragment granularity is useful
with potentially "obese" messages like Certificate.

This is the calculation I made as well. Note that re= moving aliasing in this
fashion actually is useful in measuring p= acket loss (this is what QUIC does).

=C2=A0
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex"> And what is the precise interaction between restarts, 0-RTT and message
sequence numbers on client side? As far as I can tell,
end_of_early_data is always client message_seq=3D1, and appears only iff server accepts 0-RTT. Restart client_hello is also always client
message_sseq=3D1.

That seems correct to= me.

-Ekr
=C2=A0
--001a114fcb700ee88f0552b96a05-- From nobody Sun Jun 25 02:33:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 448201296C9 for ; Sun, 25 Jun 2017 02:33:46 -0700 (PDT) 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, 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=-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 fBd4yQqnoCmb for ; Sun, 25 Jun 2017 02:33:43 -0700 (PDT) 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 5C5B81242F5 for ; Sun, 25 Jun 2017 02:33:43 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml708-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DJD77343; Sun, 25 Jun 2017 09:33:40 +0000 (GMT) Received: from DGGEMI405-HUB.china.huawei.com (10.3.17.143) by lhreml708-cah.china.huawei.com (10.201.108.49) with Microsoft SMTP Server (TLS) id 14.3.301.0; Sun, 25 Jun 2017 10:33:40 +0100 Received: from DGGEMI508-MBX.china.huawei.com ([169.254.4.203]) by dggemi405-hub.china.huawei.com ([10.3.17.143]) with mapi id 14.03.0301.000; Sun, 25 Jun 2017 17:33:27 +0800 From: yinxinxing To: "tls@ietf.org" CC: Xiongxiaochun Thread-Topic: Yin Xinxing joins the TLS WG Thread-Index: AdLtlcOB4L6nRjpaRpyixMK12/jrZA== Date: Sun, 25 Jun 2017 09:33:26 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: multipart/alternative; boundary="_000_DBDF9AE44733284D808F0E585E1919022C7891AEdggemi508mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.594F8375.005B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.203, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 03996b7b6dc723ee894887cc26454cf0 Archived-At: Subject: [TLS] Yin Xinxing joins the TLS WG X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 25 Jun 2017 09:33:46 -0000 --_000_DBDF9AE44733284D808F0E585E1919022C7891AEdggemi508mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello everyone, I am Yin Xinxing from Huawei company. I am glad to join the TLS WG. For the DLTS 1.3 draft, I am interested and have some ideas to talk with yo= u. DTLS has a lot of application scenarios in IOT fields, but currently, there= is some difficulty when DTLS 1.2 is applied to IOT devices, especially the= battery-constrained IOT devices. For example, when the IOT device wakes up from sleep mode, the NAT table ma= y have expired. Then the IOT device has to establish a new DTLS session or at least launche= s a resume process with the server, the corresponding power consumption is = too high for some power-constrained devices. How can DTLS renegotiation be avoided in order to save battery? I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider this problem= and give a proper solution. Any comment or idea about this problem is welcome. Regards, Yin Xinxing --_000_DBDF9AE44733284D808F0E585E1919022C7891AEdggemi508mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hell= o everyone,

 

I am= Yin Xinxing from Huawei company. I am glad to join the TLS WG.<= /span>

 

For = the DLTS 1.3 draft, I am interested and have some ideas to talk with you.

 

DTLS= has a lot of application scenarios in IOT fields, but currently, there is = some difficulty when DTLS 1.2 is applied to IOT devices, especially the bat= tery-constrained IOT devices.

 

For = example, when the IOT device wakes up from sleep mode, the NAT table may ha= ve expired.

Then= the IOT device has to establish a new DTLS session or at least launches a = resume process with the server, the corresponding power consumption is too = high for some power-constrained devices.

How = can DTLS renegotiation be avoided in order to save battery?

 

I ho= pe the contributors of DTLS 1.3 (or DTLS 1.2) can consider this problem and= give a proper solution.  

 

Any = comment or idea about this problem is welcome.

 

Rega= rds,

Yin = Xinxing

--_000_DBDF9AE44733284D808F0E585E1919022C7891AEdggemi508mbxchi_-- From nobody Sun Jun 25 06:33:22 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FF731277BB for ; Sun, 25 Jun 2017 06:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=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 sc-DY8_fTg-O for ; Sun, 25 Jun 2017 06:33:18 -0700 (PDT) Received: from mail-yb0-x22d.google.com (mail-yb0-x22d.google.com [IPv6:2607:f8b0:4002: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 12561126B6D for ; Sun, 25 Jun 2017 06:33:18 -0700 (PDT) Received: by mail-yb0-x22d.google.com with SMTP id e201so22888476ybb.1 for ; Sun, 25 Jun 2017 06:33:18 -0700 (PDT) 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=PDODTz+ofhP9KCGjNcwTL5aIp9L7n0VGgiXJFong0Sg=; b=tqU5YrAjUSEFrQQvOjtHQd6+3tZlKo5K/LGiAb9zlPZ9r855s54Z9UOw2Z3pWFTYTM sIlQfOYbNm84Q3OXmuIT8c11v5L80pYEgR5fBumo4Yuo9mcrucegFd1qLZGRg9ElnIwx KY1gLox5aDyXWRgPfsj0aFYmpubYEgJ+GLMsJSXoLk2xZJzCmcKdd90LIBCJzSQWmTyX aK3te0KGAL1N746HsHL93VgJIn4FSrE48Y9Ea7HdlKsgYAAfStHOR+bS97QVVtBOcksY mPbTjuDq9Rw8EVdOzzsDpSWTGAzgNIgCFuZCROvrkMH7hY/Gjb02Uzz3EwDzn5BmNeqt HIrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=PDODTz+ofhP9KCGjNcwTL5aIp9L7n0VGgiXJFong0Sg=; b=rh5tIRir+151/n9CpTXIKn8jV2Txtri+GbO/8v3OugIBh+Ane1PRiDlje2DiepTeI5 JoOfEO9w88PlakPewByUQTWQ+Ch+/vxWONiHkyfkrmFUBkNblGzALAtfgTb4zu5XusHx O9IOljI+py9kAVY8tBCyQyHkTltE/7CiSbLd6kIe60USTLxO+BidxOMiYO+wKcv+knDv iFxVBHZSZwS36iDC02X4mRZvwUsW5Wb7r5NlZbhOQ8xgpyNWKZkAuo7UYLeZG5a9rTWs tcqy+p1/s1vvyiN1EzWnB549igzU8UNbS06crMqJ5sWVrChBCz8y0RvRaF1i2Hj6ZMmP 290w== X-Gm-Message-State: AKS2vOwJbJ4bdDpkUOPWN7PCTswg1GNuvrOQXaTL5bSMS5TucK13onXb y+Yv79zqARyYZ/CWV1/Q4BBqHHSZ/nww X-Received: by 10.37.68.87 with SMTP id r84mr12678624yba.229.1498397597281; Sun, 25 Jun 2017 06:33:17 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Sun, 25 Jun 2017 06:32:36 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Sun, 25 Jun 2017 06:32:36 -0700 Message-ID: To: yinxinxing Cc: "tls@ietf.org" , Xiongxiaochun Content-Type: multipart/alternative; boundary="001a113f5f3e84eae50552c8e08a" Archived-At: Subject: Re: [TLS] Yin Xinxing joins the TLS WG X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 25 Jun 2017 13:33:20 -0000 --001a113f5f3e84eae50552c8e08a Content-Type: text/plain; charset="UTF-8" Hi Yin, The usual solution to this is to add a connection id. Please see: https://github.com/tlswg/dtls13-spec/issues/6 -Ekr On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing wrote: > Hello everyone, > > > > I am Yin Xinxing from Huawei company. I am glad to join the TLS WG. > > > > For the DLTS 1.3 draft, I am interested and have some ideas to talk with > you. > > > > DTLS has a lot of application scenarios in IOT fields, but currently, > there is some difficulty when DTLS 1.2 is applied to IOT devices, > especially the battery-constrained IOT devices. > > > > For example, when the IOT device wakes up from sleep mode, the NAT table > may have expired. > > Then the IOT device has to establish a new DTLS session or at least > launches a resume process with the server, the corresponding power > consumption is too high for some power-constrained devices. > > How can DTLS renegotiation be avoided in order to save battery? > > > > I hope the contributors of DTLS 1.3 (or DTLS 1.2) can consider this > problem and give a proper solution. > > > > Any comment or idea about this problem is welcome. > > > > Regards, > > Yin Xinxing > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a113f5f3e84eae50552c8e08a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yin,

The usual solution to this is t= o add a connection id. Please see:


On Sun, Jun 25, 2017 at 2:33 AM, yinxinxing <yinxinxing@huawei.com> wrote:

Hell= o everyone,

<= /u>=C2=A0

I am= Yin Xinxing from Huawei company. I am glad to join the TLS WG.

<= /u>=C2=A0

For = the DLTS 1.3 draft, I am interested and have some ideas to talk with you.

<= /u>=C2=A0

DTLS= has a lot of application scenarios in IOT fields, but currently, there is = some difficulty when DTLS 1.2 is applied to IOT devices, especially the bat= tery-constrained IOT devices.

<= /u>=C2=A0

For = example, when the IOT device wakes up from sleep mode, the NAT table may ha= ve expired.

Then= the IOT device has to establish a new DTLS session or at least launches a = resume process with the server, the corresponding power consumption is too = high for some power-constrained devices.

How = can DTLS renegotiation be avoided in order to save battery?

<= /u>=C2=A0

I ho= pe the contributors of DTLS 1.3 (or DTLS 1.2) can consider this problem and= give a proper solution. =C2=A0

<= /u>=C2=A0

Any = comment or idea about this problem is welcome.

<= /u>=C2=A0

Rega= rds,

Yin = Xinxing


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


--001a113f5f3e84eae50552c8e08a-- From nobody Sun Jun 25 23:43:29 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 022541242EA for ; Sun, 25 Jun 2017 23:43:28 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 JZq5bOQA3dPl for ; Sun, 25 Jun 2017 23:43:25 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id AF894120046 for ; Sun, 25 Jun 2017 23:43:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id ED65D3A218; Mon, 26 Jun 2017 09:43:22 +0300 (EEST) 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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id O0nwv08LlKZk; Mon, 26 Jun 2017 09:43:22 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 9C9C821C; Mon, 26 Jun 2017 09:43:20 +0300 (EEST) Date: Mon, 26 Jun 2017 09:43:20 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: "tls@ietf.org" Message-ID: <20170626064320.aguxkeikwdfhpnk5@LK-Perkele-VII> References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> <20170624052727.26n4spscu77nlnlw@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2017 06:43:28 -0000 On Sat, Jun 24, 2017 at 07:05:11AM -0700, Eric Rescorla wrote: > i mentioned it here, but perhaps it's not clear enough. > > "If data can be replayed a large number of times, additional attacks > become possible. Specifically, attackers can use multiple replays to > exploit information leakage via side channels such as timing network > caches or measuring the speed of cryptographic operations." > > I've got some other comments to resolve Monday I'll try to get to this then, > but I'd also welcome suggested text on the PR. I understood that the cache probing attack requires much less replays than the other side-channel ones. And furthermore, distributing the replays among zones makes the attack easier (because replay with the cached data hot doesn't tell that much). -Ilari From nobody Mon Jun 26 00:03:27 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9EE2126D74 for ; Mon, 26 Jun 2017 00:03:26 -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 VMWITZEhI0dm for ; Mon, 26 Jun 2017 00:03:25 -0700 (PDT) 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 19497120046 for ; Mon, 26 Jun 2017 00:03:25 -0700 (PDT) Received: by mail-pg0-x22c.google.com with SMTP id t186so4893804pgb.1 for ; Mon, 26 Jun 2017 00:03:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kckFJDiOa6Louh3X0F7YpIEreZVRZm9/QJ1LxJKR3X4=; b=LCYwqVcmIKoPD6D9zIGvFBkmZFs1pu6DSPA1zle11mZBG5J0kqxN6X+aafoXDNgmAq udzzp5H46dAaT0i6nsognOXHPRRm89hoNQ22qxL053Fn/c56ago7jKchXhnwgp1dpak2 ov3VBt1ZAfygvceLhh7qLrGjXQvaVgqZ3qvSSN0zlsHrwFiH6lktEfrV/rvlpJiiAd0u 9+Ax5aCi+muSRJpFazJV8LhhUfYA8P4EA7NsVzHY2/jums0JWohuGrE72MYJSDHXrJIB TfzUBLM0ArNkM5DVbzDa1gGviKLgOxkYnDFLJ0Ksjb91VfkmZF3RJVTuw7YL3YXNiwoj ERxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kckFJDiOa6Louh3X0F7YpIEreZVRZm9/QJ1LxJKR3X4=; b=uKChmUYSHgOzwp7shAI/8Z7iPo6V0AntglWEOqbbXtVehZz/AUvfIIN4RTFgqIgpjZ BmaGvjWUrjQDXVTJzYCczdow6bG+OZWRp9hdxZ/6VAZXOY+E2FzyQXd3hOmgr4xK9cDr gMSUze+K6qMGm2kzLFs5KpukiQjlcgIYPwMdfQZH/4oX4D4JpzSSwAf/wK9JoCjQQx6v nNp5YNZyu5rsliIQeX4imR5GnV9End2apIMtAcT1JY0oXojMEqKx1yFrvnR1qLl/t0lR 8GYUa6EOO6iujwWd2l/uFli1GW54xSoqwOZmcugwz5fzb++RVrGcM8JhvvcwT045lF4y aGTw== X-Gm-Message-State: AKS2vOxqTIBKzIEXuLqrh0TDpAvF6oYghu8T0K1yLDh+XwpHkR7W2MVd eHOaa+b7ONeZ2IcrvwqaPV8zjIbX98Nh X-Received: by 10.84.200.39 with SMTP id s36mr266106pld.9.1498460604665; Mon, 26 Jun 2017 00:03:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.3 with HTTP; Mon, 26 Jun 2017 00:03:24 -0700 (PDT) In-Reply-To: References: <149811425736.30341.16596521802774811431.idtracker@ietfa.amsl.com> From: Kazuho Oku Date: Mon, 26 Jun 2017 16:03:24 +0900 Message-ID: To: Martin Thomson Cc: "tls@ietf.org" , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-thomson-http-replay-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2017 07:03:27 -0000 Hi, Thank you for working on the I-D. This is a must-have and I am looking forward to seeing it standardized. H2O will implement this specification. One question: is the name `early-data` a good choice? The reason I raise the concern is because what the header suggest is if the endpoint has not yet seen a proof (i.e. ClientFinished). The name "early-data" might be confusing since it may seem to imply _when_ the request has been received rather than the current state of the connection. Other than that I the draft looks good to me. 2017-06-22 16:32 GMT+09:00 Martin Thomson : > FYI, > > Mark, Willy, and I have put together a draft that describes how HTTP > works with early data (or 0-RTT). > > The main thing of interest is the technique we recommend for avoiding > exposure to replays, particularly given that HTTP is often > intermediated. > > If you have specific comments about the draft, I'd appreciate it if > you could take those to the HTTP working group > . Of course, you should feel free to > start another massive thread about the various ways in which you think > early data represents the beginning of the end for modern > civilization. That seems to be the usual reaction to this sort of > email. > > --Martin > > ---------- Forwarded message ---------- > From: > Date: 22 June 2017 at 16:50 > Subject: New Version Notification for draft-thomson-http-replay-00.txt > > Name: draft-thomson-http-replay > Revision: 00 > Title: Using Early Data in HTTP > Document date: 2017-06-22 > Group: Individual Submission > Pages: 9 > URL: > https://www.ietf.org/internet-drafts/draft-thomson-http-replay-00.txt > Status: https://datatracker.ietf.org/doc/draft-thomson-http-replay/ > Htmlized: https://tools.ietf.org/html/draft-thomson-http-replay-00 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-thomson-http-replay-00 > > > Abstract: > This document explains the risks of using early data for HTTP and > describes techniques for reducing them. In particular, it defines a > mechanism that enables clients to communicate with servers about > early data, to assure correct operation. > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Kazuho Oku From nobody Mon Jun 26 01:01:43 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E19126C23 for ; Mon, 26 Jun 2017 01:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, 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 LM2nrCWff0Qs for ; Mon, 26 Jun 2017 01:01:41 -0700 (PDT) Received: from 1wt.eu (wtarreau.pck.nerim.net [62.212.114.60]) by ietfa.amsl.com (Postfix) with ESMTP id 75EA0127B5A for ; Mon, 26 Jun 2017 01:01:36 -0700 (PDT) Received: (from willy@localhost) by pcw.home.local (8.15.2/8.15.2/Submit) id v5Q81VNb003927; Mon, 26 Jun 2017 10:01:31 +0200 Date: Mon, 26 Jun 2017 10:01:31 +0200 From: Willy Tarreau To: Kazuho Oku Cc: Martin Thomson , "tls@ietf.org" , HTTP Working Group Message-ID: <20170626080131.GC3730@1wt.eu> References: <149811425736.30341.16596521802774811431.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1 (2016-04-27) Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-thomson-http-replay-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2017 08:01:42 -0000 Hi Kazuho, On Mon, Jun 26, 2017 at 04:03:24PM +0900, Kazuho Oku wrote: > One question: is the name `early-data` a good choice? > > The reason I raise the concern is because what the header suggest is > if the endpoint has not yet seen a proof (i.e. ClientFinished). The > name "early-data" might be confusing since it may seem to imply _when_ > the request has been received rather than the current state of the > connection. You mean that you'd prefer something indicating that there were unsafe (ie not yet validated) early data in fact, that's it ? Willy From nobody Mon Jun 26 10:25:51 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5299129C0E for ; Mon, 26 Jun 2017 10:25:50 -0700 (PDT) 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=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 vHOStsuA34l5 for ; Mon, 26 Jun 2017 10:25:49 -0700 (PDT) Received: from mail-yb0-x229.google.com (mail-yb0-x229.google.com [IPv6:2607:f8b0:4002: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 5F85012EAF3 for ; Mon, 26 Jun 2017 10:25:48 -0700 (PDT) Received: by mail-yb0-x229.google.com with SMTP id s9so2440502ybe.3 for ; Mon, 26 Jun 2017 10:25:48 -0700 (PDT) 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=OLdYXDMN6F9ebL0d/qoADHSciGAHtEkuXoN+J6F/Z9g=; b=1Qz2euGHTqoi4S2zapZS7yQ9Oikxj1+SHs46UIk3zHyV1vOAlTTl5O3ZwouuG4NEeg KAoo3YWOlrKjvzATOec3mElWe2HQghL+m8/t+4NtzjIzNO7VwXwfKZ8HXQtdOLSDeCQG wovWaMAqTAqNXiILAg4PHiWeyJ4X/ho+mNdVv8/awOF4WMTnjMaQm1GKWTf4/ANmCUTn wUzXQwEdo8NEYZ6zgOpO8m9vdMaD4LjHDf7SyZdGt1A4pSzDAd8X8r6JPmREW/BGYwXl aJLOXxv9K9ivTZKpLdDE8A6C0nTthq6YpKAl7OTzFwFzBJwp+0Nuh2y2VXMRLkxRwRUX 78vA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OLdYXDMN6F9ebL0d/qoADHSciGAHtEkuXoN+J6F/Z9g=; b=nvJY8204svggg6kdYvZa46TJsOih9JR8jzBSfUjLnLsH8gziMRXbgqfDZdr1asR+GV 4H2cydnDzUSaFWCHO5qDWFMeIzoL7hSGGIThPlasi5oW3boY7/8FtnuQIZXairjrn/Pk G1AV7VFJm1MUhA9Ex8qCYmL0N0yofs6ITtCNk/KL0rmeE9DFtVIsgtUt24yZJ2NtgkCG JrvcVQNmJlNMP+I2GKHGbXXxBffDWtfJ0Ib3fFJoKuX4SdhBdahM8WvRVwJDX8FEMMrk S/ufcJzjyPzdQ2Wwszm3XNGtrRnSfzreYcGp38FlVaFd38xcm4CfPNrFadkLluRLZteW AThg== X-Gm-Message-State: AKS2vOxXOzA8rYa7Ynw+8aB9lUplJlIGhPbr5vjFXkkQFwRNlG34+5rD Tdwuu8jS+AzrVTNpdc638KG8uyna4Vp9 X-Received: by 10.37.22.213 with SMTP id 204mr925114ybw.204.1498497947459; Mon, 26 Jun 2017 10:25:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.93.197 with HTTP; Mon, 26 Jun 2017 10:25:46 -0700 (PDT) In-Reply-To: <20170626064320.aguxkeikwdfhpnk5@LK-Perkele-VII> References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> <20170624052727.26n4spscu77nlnlw@LK-Perkele-VII> <20170626064320.aguxkeikwdfhpnk5@LK-Perkele-VII> From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Date: Mon, 26 Jun 2017 10:25:46 -0700 Message-ID: To: Ilari Liusvaara Cc: Eric Rescorla , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11c13388db2f990552e03d99" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2017 17:25:51 -0000 --001a11c13388db2f990552e03d99 Content-Type: text/plain; charset="UTF-8" On Sun, Jun 25, 2017 at 11:43 PM, Ilari Liusvaara wrote: > I understood that the cache probing attack requires much less replays > than the other side-channel ones. And furthermore, distributing the > replays among zones makes the attack easier (because replay with the > cached data hot doesn't tell that much). > In practice with real world HTTP caches, one replay is often sufficient. That's because in addition to the faster load time you can look at the cache headers (like max-age) to pinpoint that it was the replay that put the item in the cache. This would work with DNS too, where TTL or RRSET cycling leaks more information in the same way. Using more zones does help, and if the attacker were targeting a busy cache, then it can certainly help to weed out the noise and increase the likelihood of finding a zone/node where the cache is empty to begin with. -- Colm --001a11c13388db2f990552e03d99 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Jun 25, 2017 at 11:43 PM, Ilari Liusvaara <= ;ilariliusvaa= ra@welho.com> wrote:
I unde= rstood that the cache probing attack requires much less replays
than the other side-channel ones. And furthermore, distributing the
replays among zones makes the attack easier (because replay with the
cached data hot doesn't tell that much).

In practice with real world HTTP caches, one replay is often sufficie= nt. That's because in addition to the faster load time you can look at = the cache headers (like max-age) to pinpoint that it was the replay that pu= t the item in the cache. This would work with DNS too, where TTL or RRSET c= ycling leaks more information in the same way. =C2=A0

<= div>Using more zones does help, and if the attacker were targeting a busy c= ache, then it can certainly help to weed out the noise and increase the lik= elihood of finding a zone/node where the cache is empty to begin with.=C2= =A0

--
Colm
--001a11c13388db2f990552e03d99-- From nobody Mon Jun 26 11:16:46 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EB412EB2B for ; Mon, 26 Jun 2017 11:16:45 -0700 (PDT) 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 g0zOKS_hdth4 for ; Mon, 26 Jun 2017 11:16:43 -0700 (PDT) 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 979A412EAFB for ; Mon, 26 Jun 2017 11:16:43 -0700 (PDT) Received: by mail-yw0-x229.google.com with SMTP id s127so3693886ywg.1 for ; Mon, 26 Jun 2017 11:16:43 -0700 (PDT) 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=FJilpDKSvAzCBZ4PA8JQ/fsF0fWBtd0vEUNC8wZ+9EI=; b=Svp7S5Cz6nTuw8IiIlHBk5XYmwPiHM012GXB9uSjtGtPMl8WBgBkNz3wh6ZvTeevG4 OzSILnkZO8B/yLJR2VbLJUonIm//t29j5dj3VwGDopGo1JgPz7Wqke9ET+SMh0pTvAUU QDLQO9CsbWjr2cPUGXWadJxkI4kdGyMw0W7l1piVOqdgwEtHHkEBC9U+0Sm58Wh8I6db NS/dOW/RacPRfCtHHjeyYOGiPsuJ6HGnL7HmRUcAISPVI9LUxPUjyzS6aUhpjZPvxtKe YLRnpRIA50jps3n9Jv3nNDep02oWsZqZ8bQYijystQK3jl5fpFbZCwB7k9dHREC0KXq0 /VVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=FJilpDKSvAzCBZ4PA8JQ/fsF0fWBtd0vEUNC8wZ+9EI=; b=IoZDubv/sF7P3QE3a6RxXJAnbml3y2VcZN6/tCcigR9FFIqOCF69w7fIF670sgk3Hx l+65dQJeEkS1HcbFDT5dho3ptzgCb2weyb84OEEc9WIEHx+w2/5Lx3rV54KfJcmtpD9c 8BwikFobtI68m2ksek/REh1NA3Y5BxyMO+p/ws/G8iMK9aZEdsmUIwgLnGFDXgTqj1dn Tgr5Sd1VUkap5zH8DdICnTLUN1qsgTQ+3Ja1n5Jl6jIb4Idti6N7TVMvnedDocKtvBIB y3hi6t7cMOK+IhtRN38f6a8HgOxtBZrDQkBC7/t4g2EoxO+VTGPtMstmWZHm2Ev5qfww j5cw== X-Gm-Message-State: AKS2vOy+AqzORLJ6HbUnoh5vzEtz+KiGngd7hhCahJZ6goPFdXtr9GnV 7IhMp8etMPVtF/k5eBFoYYDBWaHr8v4a X-Received: by 10.129.50.140 with SMTP id y134mr1035133ywy.312.1498501002700; Mon, 26 Jun 2017 11:16:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Mon, 26 Jun 2017 11:16:02 -0700 (PDT) In-Reply-To: References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> <20170624052727.26n4spscu77nlnlw@LK-Perkele-VII> <20170626064320.aguxkeikwdfhpnk5@LK-Perkele-VII> From: Eric Rescorla Date: Mon, 26 Jun 2017 11:16:02 -0700 Message-ID: To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Cc: Ilari Liusvaara , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a1140932af653590552e0f3a2" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2017 18:16:45 -0000 --001a1140932af653590552e0f3a2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable OK, I'll move this out of the "if you can do a lot of replays" section On Mon, Jun 26, 2017 at 10:25 AM, Colm MacC=C3=A1rthaigh wrote: > > > On Sun, Jun 25, 2017 at 11:43 PM, Ilari Liusvaara < > ilariliusvaara@welho.com> wrote: > >> I understood that the cache probing attack requires much less replays >> than the other side-channel ones. And furthermore, distributing the >> replays among zones makes the attack easier (because replay with the >> cached data hot doesn't tell that much). >> > > In practice with real world HTTP caches, one replay is often sufficient. > That's because in addition to the faster load time you can look at the > cache headers (like max-age) to pinpoint that it was the replay that put > the item in the cache. This would work with DNS too, where TTL or RRSET > cycling leaks more information in the same way. > > Using more zones does help, and if the attacker were targeting a busy > cache, then it can certainly help to weed out the noise and increase the > likelihood of finding a zone/node where the cache is empty to begin with. > > -- > Colm > --001a1140932af653590552e0f3a2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK, I'll move this out of the "if you can do a lo= t of replays" section

On Mon, Jun 26, 2017 at 10:25 AM, Colm MacC=C3=A1rthaigh <= span dir=3D"ltr"><colm@allcosts.net> wrote:
=


On Sun, Jun 25, 2017 at 11:43 PM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
I understood that the cache probing attack requires much less re= plays
than the other side-channel ones. And furthermore, distributing the
replays among zones makes the attack easier (because replay with the
cached data hot doesn't tell that much).

In practice with real world HTTP caches, one replay is often s= ufficient. That's because in addition to the faster load time you can l= ook at the cache headers (like max-age) to pinpoint that it was the replay = that put the item in the cache. This would work with DNS too, where TTL or = RRSET cycling leaks more information in the same way. =C2=A0

=
Using more zones does help, and if the attacker were targeting a= busy cache, then it can certainly help to weed out the noise and increase = the likelihood of finding a zone/node where the cache is empty to begin wit= h.=C2=A0
--
Colm

--001a1140932af653590552e0f3a2-- From nobody Mon Jun 26 15:15:48 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 228CE12EB77 for ; Mon, 26 Jun 2017 15:15:46 -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 (2048-bit key) header.d=mnot.net header.b=LsNmyJdT; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=byMZSQbX Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZAPxQzPsyCXa for ; Mon, 26 Jun 2017 15:15:43 -0700 (PDT) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 270DC12EB74 for ; Mon, 26 Jun 2017 15:15:43 -0700 (PDT) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailnew.nyi.internal (Postfix) with ESMTP id 84C7FE9F; Mon, 26 Jun 2017 18:15:42 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Mon, 26 Jun 2017 18:15:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mnot.net; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc:x-sasl-enc; s=fm1; bh=Uyig2aytbZwIq+5J5w MN1GTEELrGJEbH9qWSuc8OKts=; b=LsNmyJdTuxoMx79MigksoaCAkYAQq89L3w POIRxdhViOk5wd56D44dmQY2cVap0dCPbiarJVpq67aI80H1n1pAC+TUoQyCRNys Jy/tjTO/6fXxNkuVOWKxgAR4ZUtg1hJXdxyoy+Qx8wllDRMG6vzWTtkr7XTiH2ST at507WPLJceoILraPouzyXxuV3yZBetnEzNelN7IPqd9noEUx49g6Cyw4tG93UGo /dGdJC6XEod4G1I8808pY9nRQoblJTE5+lYqDJqg00t66YoNArPnUXPc1jfKQXm3 /27lKVkpBCmD7hcMW+XFCUW4P4lEt/+XOWZLV/jwhCM70eXTEAZw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc:x-sasl-enc; s= fm1; bh=Uyig2aytbZwIq+5J5wMN1GTEELrGJEbH9qWSuc8OKts=; b=byMZSQbX yhDNABgbH94VgMTYs/I6DIQCJYpR7wFO8XodPGVL+J9srPVUNPXePBOopqnSv1tI MHBtT7suhgbMJ9uEKTWutOFvjqdx9B4DdpM/9K7vK6biS69eDdGpCoFjTml0Q0ts fD+IJMwyhVW8rPdpCvHrdTcA3h8YvHwq/vHg2Lerge+A/3r28cJvzjQ4kZChslJE ecHBu6yflNQdgylp2oNJFp2cI65OZwW0S/FKhS5RIIIbDdT90D/biFwdR8ni6Wn3 /OSy39o6mBB/TtmGQVyGAlpIXVP1E5BHvwiNNnVLVgCzkjB+rFo8E2zVcMWJ8tyu 9IOxH8X9HeiYog== X-ME-Sender: X-Sasl-enc: XnljYae3nlsKpxZXKVGsCFnd6kuvmFc8nolebzdnlcqR 1498515341 Received: from [192.168.1.18] (cpe-124-188-19-231.hdbq1.win.bigpond.net.au [124.188.19.231]) by mail.messagingengine.com (Postfix) with ESMTPA id 0EEC17E263; Mon, 26 Jun 2017 18:15:40 -0400 (EDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Mark Nottingham In-Reply-To: Date: Tue, 27 Jun 2017 08:15:38 +1000 Cc: Ilari Liusvaara , "tls@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170613113232.GC8983@LK-Perkele-V2.elisa-laajakaista.fi> <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> <20170624052727.26n4spscu77nlnlw@LK-Perkele-VII> <20170626064320.aguxkeikwdfhpnk5@LK-Perkele-VII> To: =?utf-8?Q?Colm_MacC=C3=A1rthaigh?= X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2017 22:15:46 -0000 > On 27 Jun 2017, at 3:25 am, Colm MacC=C3=A1rthaigh = wrote: >=20 >=20 >=20 > On Sun, Jun 25, 2017 at 11:43 PM, Ilari Liusvaara = wrote: > I understood that the cache probing attack requires much less replays > than the other side-channel ones. And furthermore, distributing the > replays among zones makes the attack easier (because replay with the > cached data hot doesn't tell that much). >=20 > In practice with real world HTTP caches, one replay is often = sufficient. That's because in addition to the faster load time you can = look at the cache headers (like max-age) I think you mean Age.=20 > to pinpoint that it was the replay that put the item in the cache. = This would work with DNS too, where TTL or RRSET cycling leaks more = information in the same way. =20 >=20 > Using more zones does help, and if the attacker were targeting a busy = cache, then it can certainly help to weed out the noise and increase the = likelihood of finding a zone/node where the cache is empty to begin = with.=20 Cheers, -- Mark Nottingham https://www.mnot.net/ From nobody Mon Jun 26 15:26:15 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDA6E12EB77 for ; Mon, 26 Jun 2017 15:26:12 -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 rPJYeR9amKFg for ; Mon, 26 Jun 2017 15:26:11 -0700 (PDT) Received: from mail-pf0-x233.google.com (mail-pf0-x233.google.com [IPv6:2607:f8b0:400e:c00::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 2D89612EB72 for ; Mon, 26 Jun 2017 15:26:11 -0700 (PDT) Received: by mail-pf0-x233.google.com with SMTP id e7so6707495pfk.0 for ; Mon, 26 Jun 2017 15:26:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=W6cZCKyon72/06EBPASH1no9hBXvC9ELsDMzKWTw5zA=; b=FnL8fU+Tb5yauSlNu7ZNIoCd/cQyboJG3KN9oqJGQA6OIXnQZ+IT03FRqX+LHCSJMF U8VnUywxqyXg1h0Zv74jEI//JMU2I1ol7BwkLleUdf8O9jX2ioIHsYCq8QWhlg+vGEXj FcgrYr39ZJ+U59MTh1PpkCRfAlrzgVd/Jeoh5Y7rxx0RtV1jQoBKqtpZq2c/g9AYdJDl vNwLNVfMUic3zNwZGav+XFS5FRLW6NGWecsMK/CVwXEq7Q9eU1iSaZJe59S/bPLLq2KN 41OI5wRAZLfNmciClIfRvtgaQghY8IDzEAvhTPfF3323mnmT6ePtGWxmK8DMzAB4g5zZ Tv1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W6cZCKyon72/06EBPASH1no9hBXvC9ELsDMzKWTw5zA=; b=UyVX73TB50fr5OFdD/RxMQDuUqcMkzePs8cBe8Djwf3M+z+ebndaHbi2ilZ/ZNp+ve f7YyMC2AvnrD3q4nFxmOhRWPsFydGicSzc7tEDwiZqu46j2pNCmv1iv4g/HMtC+IgG71 tT9jpCTru8OTDh1aFUCwhzrPyGs0TIZeFIj7lORz5jEP5HP72gtDaviZ+EvbTgAKZ7hB s6TG7MwuVcdOFQGY4+IBdmjNVufTTAGr715Ax4zRECOh6vYmzl5EW7J4cjJy+rt5vmfz 6Uvb+zdMSpwKkyZ/SP4j9PHyhgv+aAAHu8EGSwAtfESjVGQT15V0T2o5lVSmpo6IjhoJ 6PJQ== X-Gm-Message-State: AKS2vOwV2Xcv94RQrmZ5DIg/TOTozJBLx8Wg1N7DOoGUCTwwDt5RZh6H TnGOiEgQUCYUpgM0a9ipgncS2EUc3g== X-Received: by 10.99.45.6 with SMTP id t6mr2151779pgt.209.1498515970773; Mon, 26 Jun 2017 15:26:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.130.3 with HTTP; Mon, 26 Jun 2017 15:26:10 -0700 (PDT) In-Reply-To: <20170626080131.GC3730@1wt.eu> References: <149811425736.30341.16596521802774811431.idtracker@ietfa.amsl.com> <20170626080131.GC3730@1wt.eu> From: Kazuho Oku Date: Tue, 27 Jun 2017 07:26:10 +0900 Message-ID: To: Willy Tarreau Cc: Martin Thomson , "tls@ietf.org" , HTTP Working Group Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [TLS] Fwd: New Version Notification for draft-thomson-http-replay-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 26 Jun 2017 22:26:13 -0000 Hi Willy, 2017-06-26 17:01 GMT+09:00 Willy Tarreau : > Hi Kazuho, > > On Mon, Jun 26, 2017 at 04:03:24PM +0900, Kazuho Oku wrote: >> One question: is the name `early-data` a good choice? >> >> The reason I raise the concern is because what the header suggest is >> if the endpoint has not yet seen a proof (i.e. ClientFinished). The >> name "early-data" might be confusing since it may seem to imply _when_ >> the request has been received rather than the current state of the >> connection. > > You mean that you'd prefer something indicating that there were unsafe > (ie not yet validated) early data in fact, that's it ? Yes. That was my intention. > Willy -- Kazuho Oku From nobody Tue Jun 27 01:27:53 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6544F12EB9A for ; Tue, 27 Jun 2017 01:27:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 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=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 RkXZ7q9jamZp for ; Tue, 27 Jun 2017 01:27:49 -0700 (PDT) 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 D7F9A12942F for ; Tue, 27 Jun 2017 01:27:47 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPX10319; Tue, 27 Jun 2017 08:27:45 +0000 (GMT) Received: from DGGEMI401-HUB.china.huawei.com (10.3.17.134) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 27 Jun 2017 09:27:45 +0100 Received: from DGGEMI508-MBX.china.huawei.com ([169.254.4.203]) by dggemi401-hub.china.huawei.com ([10.3.17.134]) with mapi id 14.03.0301.000; Tue, 27 Jun 2017 16:27:31 +0800 From: yinxinxing To: Eric Rescorla CC: "tls@ietf.org" , Tobias Gondrom Thread-Topic: [TLS] Yin Xinxing joins the TLS WG Thread-Index: AdLvHzT4wQD8dGRmTQq9MiSajUZKEg== Date: Tue, 27 Jun 2017 08:27:31 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.225.248] Content-Type: multipart/alternative; boundary="_000_DBDF9AE44733284D808F0E585E1919022C7896F8dggemi508mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59521702.003F, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.4.203, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: f05ba08519def442712872b3c949da1d Archived-At: Subject: Re: [TLS] Yin Xinxing joins the TLS WG X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2017 08:27:51 -0000 --_000_DBDF9AE44733284D808F0E585E1919022C7896F8dggemi508mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhbmtzIEVyaWMsDQoNCkkgaGF2ZSBzZWVuIHRoZSBDSUQgc2NoZW1lLCBhbmQgdGFsa2VkIHdp dGggSGFubmVzKHRoZSBhdXRob3Igb2YgdGhlIHNjaGVtZSkuDQoNCkNJRCBzY2hlbWUgaXMgYSBn b29kIGlkZWEgdG8gc29sdmUgdGhlIHByb2JsZW0gSSBtZW50aW9uZWQuDQoNCkkgdGhpbmsgdGhl IGxlbmd0aCBvZiBDSUQgKGN1cnJlbnRseSwgaXQgaXMgMzIgYml0cykgY2FuIGJlIGxvbmdlciBz byB0aGF0IGl0IGNhbiBzdXBwb3J0IG1vcmUgRFRMUyBzZXNzaW9ucy4gSXQgaXMga25vd24gdGhh dCBmb3IgSU9UIHNjZW5hcmlvLCAxIG1pbGxpb24gY29ubmVjdGlvbiBpcyBub3RoaW5nLg0KDQpS ZWdhcmRzLA0KWWluIFhpbnhpbmcNCg0K5Y+R5Lu25Lq6OiBFcmljIFJlc2NvcmxhIFttYWlsdG86 ZWtyQHJ0Zm0uY29tXQ0K5Y+R6YCB5pe26Ze0OiAyMDE35bm0NuaciDI15pelIDIxOjMzDQrmlLbk u7bkuro6IHlpbnhpbnhpbmcNCuaKhOmAgTogdGxzQGlldGYub3JnOyBYaW9uZ3hpYW9jaHVuDQrk uLvpopg6IFJlOiBbVExTXSBZaW4gWGlueGluZyBqb2lucyB0aGUgVExTIFdHDQoNCkhpIFlpbiwN Cg0KVGhlIHVzdWFsIHNvbHV0aW9uIHRvIHRoaXMgaXMgdG8gYWRkIGEgY29ubmVjdGlvbiBpZC4g UGxlYXNlIHNlZToNCmh0dHBzOi8vZ2l0aHViLmNvbS90bHN3Zy9kdGxzMTMtc3BlYy9pc3N1ZXMv Ng0KDQotRWtyDQoNCg0KDQoNCk9uIFN1biwgSnVuIDI1LCAyMDE3IGF0IDI6MzMgQU0sIHlpbnhp bnhpbmcgPHlpbnhpbnhpbmdAaHVhd2VpLmNvbTxtYWlsdG86eWlueGlueGluZ0BodWF3ZWkuY29t Pj4gd3JvdGU6DQpIZWxsbyBldmVyeW9uZSwNCg0KSSBhbSBZaW4gWGlueGluZyBmcm9tIEh1YXdl aSBjb21wYW55LiBJIGFtIGdsYWQgdG8gam9pbiB0aGUgVExTIFdHLg0KDQpGb3IgdGhlIERMVFMg MS4zIGRyYWZ0LCBJIGFtIGludGVyZXN0ZWQgYW5kIGhhdmUgc29tZSBpZGVhcyB0byB0YWxrIHdp dGggeW91Lg0KDQpEVExTIGhhcyBhIGxvdCBvZiBhcHBsaWNhdGlvbiBzY2VuYXJpb3MgaW4gSU9U IGZpZWxkcywgYnV0IGN1cnJlbnRseSwgdGhlcmUgaXMgc29tZSBkaWZmaWN1bHR5IHdoZW4gRFRM UyAxLjIgaXMgYXBwbGllZCB0byBJT1QgZGV2aWNlcywgZXNwZWNpYWxseSB0aGUgYmF0dGVyeS1j b25zdHJhaW5lZCBJT1QgZGV2aWNlcy4NCg0KRm9yIGV4YW1wbGUsIHdoZW4gdGhlIElPVCBkZXZp Y2Ugd2FrZXMgdXAgZnJvbSBzbGVlcCBtb2RlLCB0aGUgTkFUIHRhYmxlIG1heSBoYXZlIGV4cGly ZWQuDQpUaGVuIHRoZSBJT1QgZGV2aWNlIGhhcyB0byBlc3RhYmxpc2ggYSBuZXcgRFRMUyBzZXNz aW9uIG9yIGF0IGxlYXN0IGxhdW5jaGVzIGEgcmVzdW1lIHByb2Nlc3Mgd2l0aCB0aGUgc2VydmVy LCB0aGUgY29ycmVzcG9uZGluZyBwb3dlciBjb25zdW1wdGlvbiBpcyB0b28gaGlnaCBmb3Igc29t ZSBwb3dlci1jb25zdHJhaW5lZCBkZXZpY2VzLg0KSG93IGNhbiBEVExTIHJlbmVnb3RpYXRpb24g YmUgYXZvaWRlZCBpbiBvcmRlciB0byBzYXZlIGJhdHRlcnk/DQoNCkkgaG9wZSB0aGUgY29udHJp YnV0b3JzIG9mIERUTFMgMS4zIChvciBEVExTIDEuMikgY2FuIGNvbnNpZGVyIHRoaXMgcHJvYmxl bSBhbmQgZ2l2ZSBhIHByb3BlciBzb2x1dGlvbi4NCg0KQW55IGNvbW1lbnQgb3IgaWRlYSBhYm91 dCB0aGlzIHByb2JsZW0gaXMgd2VsY29tZS4NCg0KUmVnYXJkcywNCllpbiBYaW54aW5nDQoNCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpUTFMgbWFpbGlu ZyBsaXN0DQpUTFNAaWV0Zi5vcmc8bWFpbHRvOlRMU0BpZXRmLm9yZz4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzDQoNCg== --_000_DBDF9AE44733284D808F0E585E1919022C7896F8dggemi508mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 5a6L5L2TOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OuW+rui9r+mbhem7kTsN CglwYW5vc2UtMToyIDExIDUgMyAyIDIgNCAyIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFt aWx5OiJcQOWui+S9kyI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OiJcQOW+rui9r+mbhem7kSI7DQoJcGFub3NlLTE6MiAxMSA1IDMg MiAyIDQgMiAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5N c29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseTrlrovkvZM7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg OTAuMHB0IDcyLjBwdCA5MC4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJaSC1DTiIgbGluaz0iYmx1ZSIgdmxpbms9 InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdE Ij5UaGFua3MgRXJpYyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SSBoYXZl IHNlZW4gdGhlIENJRCBzY2hlbWUsIGFuZCB0YWxrZWQgd2l0aCBIYW5uZXModGhlIGF1dGhvciBv ZiB0aGUgc2NoZW1lKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+Q0lEIHNj aGVtZSBpcyBhIGdvb2QgaWRlYSB0byBzb2x2ZSB0aGUgcHJvYmxlbSBJIG1lbnRpb25lZC4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj5JIHRoaW5rIHRoZSBsZW5ndGggb2Yg Q0lEIChjdXJyZW50bHksIGl0IGlzIDMyIGJpdHMpIGNhbiBiZSBsb25nZXIgc28gdGhhdCBpdCBj YW4gc3VwcG9ydCBtb3JlIERUTFMgc2Vzc2lvbnMuIEl0IGlzIGtub3duIHRoYXQgZm9yIElPVCBz Y2VuYXJpbywNCiAxIG1pbGxpb24gY29ubmVjdGlvbiBpcyBub3RoaW5nLjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjojMUY0OTdEIj5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjEw LjVwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDs7Y29sb3I6IzFGNDk3RCI+WWluIFhpbnhpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC41 cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O+W+rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7lj5Hku7bkuro8 c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bhbj48L3NwYW4+PC9iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5EmcXVv dDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+IEVyaWMgUmVzY29ybGEgW21haWx0bzpla3JAcnRm bS5jb21dDQo8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q75b6u6L2v6ZuF6buRJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PuWPkemAgeaXtumXtDxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvc3Bhbj48L2I+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O+W+ rui9r+mbhem7kSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4gMjAxNzwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDvlvq7ova/pm4Xpu5Em cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+5bm0PHNwYW4gbGFuZz0iRU4tVVMiPjY8L3Nw YW4+5pyIPHNwYW4gbGFuZz0iRU4tVVMiPjI1PC9zcGFuPuaXpTxzcGFuIGxhbmc9IkVOLVVTIj4N CiAyMTozMzxicj4NCjwvc3Bhbj48Yj7mlLbku7bkuro8c3BhbiBsYW5nPSJFTi1VUyI+Ojwvc3Bh bj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiB5aW54aW54aW5nPGJyPg0KPC9zcGFuPjxiPuaKhOmA gTxzcGFuIGxhbmc9IkVOLVVTIj46PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyI+IHRsc0Bp ZXRmLm9yZzsgWGlvbmd4aWFvY2h1bjxicj4NCjwvc3Bhbj48Yj7kuLvpopg8c3BhbiBsYW5nPSJF Ti1VUyI+Ojwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSZTogW1RMU10gWWluIFhpbnhp bmcgam9pbnMgdGhlIFRMUyBXRzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IaSBZ aW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+VGhlIHVzdWFsIHNv bHV0aW9uIHRvIHRoaXMgaXMgdG8gYWRkIGEgY29ubmVjdGlvbiBpZC4gUGxlYXNlIHNlZTo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL3Rsc3dnL2R0bHMx My1zcGVjL2lzc3Vlcy82Ij5odHRwczovL2dpdGh1Yi5jb20vdGxzd2cvZHRsczEzLXNwZWMvaXNz dWVzLzY8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVT Ij4tRWtyPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5PbiBTdW4sIEp1biAyNSwgMjAxNyBhdCAyOjMzIEFN LCB5aW54aW54aW5nICZsdDs8YSBocmVmPSJtYWlsdG86eWlueGlueGluZ0BodWF3ZWkuY29tIiB0 YXJnZXQ9Il9ibGFuayI+eWlueGlueGluZ0BodWF3ZWkuY29tPC9hPiZndDsgd3JvdGU6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1s ZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowY20gMGNtIDBjbSA2LjBwdDttYXJnaW4t bGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkhl bGxvIGV2ZXJ5b25lLA0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SSBhbSBZaW4gWGlueGluZyBmcm9tIEh1YXdlaSBj b21wYW55LiBJIGFtIGdsYWQgdG8gam9pbiB0aGUgVExTIFdHLjwvc3Bhbj48c3BhbiBsYW5nPSJF Ti1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48c3Bh biBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZvciB0aGUg RExUUyAxLjMgZHJhZnQsIEkgYW0gaW50ZXJlc3RlZCBhbmQgaGF2ZSBzb21lIGlkZWFzIHRvIHRh bGsgd2l0aCB5b3UuDQo8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0 bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5EVExTIGhhcyBhIGxvdCBvZiBhcHBsaWNhdGlvbiBz Y2VuYXJpb3MgaW4gSU9UIGZpZWxkcywgYnV0IGN1cnJlbnRseSwgdGhlcmUgaXMgc29tZSBkaWZm aWN1bHR5IHdoZW4gRFRMUyAxLjIgaXMgYXBwbGllZCB0byBJT1QgZGV2aWNlcywNCiBlc3BlY2lh bGx5IHRoZSBiYXR0ZXJ5LWNvbnN0cmFpbmVkIElPVCBkZXZpY2VzLjwvc3Bhbj48c3BhbiBsYW5n PSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZvciBl eGFtcGxlLCB3aGVuIHRoZSBJT1QgZGV2aWNlIHdha2VzIHVwIGZyb20gc2xlZXAgbW9kZSwgdGhl IE5BVCB0YWJsZSBtYXkgaGF2ZSBleHBpcmVkLg0KPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhlbiB0aGUgSU9UIGRldmljZSBoYXMg dG8gZXN0YWJsaXNoIGEgbmV3IERUTFMgc2Vzc2lvbiBvciBhdCBsZWFzdCBsYXVuY2hlcyBhIHJl c3VtZSBwcm9jZXNzIHdpdGggdGhlIHNlcnZlciwgdGhlIGNvcnJlc3BvbmRpbmcgcG93ZXINCiBj b25zdW1wdGlvbiBpcyB0b28gaGlnaCBmb3Igc29tZSBwb3dlci1jb25zdHJhaW5lZCBkZXZpY2Vz LiA8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5Ib3cgY2FuIERUTFMgcmVuZWdvdGlhdGlvbiBiZSBhdm9pZGVkIGluIG9yZGVyIHRvIHNh dmUgYmF0dGVyeT88L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIGhvcGUgdGhlIGNvbnRyaWJ1dG9ycyBvZiBEVExTIDEu MyAob3IgRFRMUyAxLjIpIGNhbiBjb25zaWRlciB0aGlzIHByb2JsZW0gYW5kIGdpdmUgYSBwcm9w ZXIgc29sdXRpb24uICZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFueSBjb21tZW50IG9yIGlkZWEgYWJvdXQg dGhpcyBwcm9ibGVtIGlzIHdlbGNvbWUuPC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVT Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIGxh bmc9IkVOLVVTIiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UmVnYXJkcyw8L3NwYW4+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 byI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5ZaW4gWGlueGlu Zzwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBw dCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fPGJyPg0KVExTIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1h aWx0bzpUTFNAaWV0Zi5vcmciPlRMU0BpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3RscyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPC9hPjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_DBDF9AE44733284D808F0E585E1919022C7896F8dggemi508mbxchi_-- From nobody Tue Jun 27 11:49:15 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC7D12EB04 for ; Tue, 27 Jun 2017 11:49:14 -0700 (PDT) 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, RP_MATCHES_RCVD=-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 KMwj1475B8U0 for ; Tue, 27 Jun 2017 11:49:12 -0700 (PDT) Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 003951292F5 for ; Tue, 27 Jun 2017 11:49:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id A8B133A307; Tue, 27 Jun 2017 21:49:10 +0300 (EEST) 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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id tXcUp3pCS1gy; Tue, 27 Jun 2017 21:49:10 +0300 (EEST) Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 4C6122316; Tue, 27 Jun 2017 21:49:07 +0300 (EEST) Date: Tue, 27 Jun 2017 21:49:07 +0300 From: Ilari Liusvaara To: Eric Rescorla Cc: Colm =?utf-8?Q?MacC=C3=A1rthaigh?= , "tls@ietf.org" Message-ID: <20170627184907.oollf5evznyek5tg@LK-Perkele-VII> References: <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> <20170624052727.26n4spscu77nlnlw@LK-Perkele-VII> <20170626064320.aguxkeikwdfhpnk5@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20170609 (1.8.3) Sender: ilariliusvaara@welho.com Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 27 Jun 2017 18:49:14 -0000 On Mon, Jun 26, 2017 at 11:16:02AM -0700, Eric Rescorla wrote: > OK, I'll move this out of the "if you can do a lot of replays" section > Another thing: The PR briefly mentions to be careful with 0-RTT exporters, but nothing concrete-looking. If 0-RTT data is replayed and the replay accepted, all replays share the same 0-RTT exporter values. This causes two kinds of problems: 1) If 0-RTT exporters are used for authentication, then an attacker in possession of resumption secret and DHE key (if any) can replay the generated tokens to another connection with replayed 0-RTT, even without the better-protected authentication key. 2) If 0-RTT exporters are used for key material for to-client direction, then the replays will have the same keying material, which is highly dangerous with many encryption algorithms. -Ilari From nobody Wed Jun 28 11:16:33 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FAAF12EA97 for ; Wed, 28 Jun 2017 11:16:32 -0700 (PDT) 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=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 UR4fTmw5rSXC for ; Wed, 28 Jun 2017 11:16:30 -0700 (PDT) Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::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 A357F12EA96 for ; Wed, 28 Jun 2017 11:16:30 -0700 (PDT) Received: by mail-qt0-x22e.google.com with SMTP id i2so56327326qta.3 for ; Wed, 28 Jun 2017 11:16:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sn3rd.com; s=google; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=Kgj+RyWB/3vYx+LPk7uwZa5IRxf+2FMU1NVK0gEFTsE=; b=HiVPzgHFlU/JkIydHD26femaSj1twqCWVrRpGr9Qs8iQX/lu6EHD/pKt6c6fXKm6jg VjKwtkHBOyQ6m2Q6amBYpwLHTzD4q8XvBM50vy+tPj/pr7Z0LFklCJOBgKVTrN0s9ssW BA0ZdypUFfiV4Mp++kbMSgZ+W2w4ChfZP3m1w= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=Kgj+RyWB/3vYx+LPk7uwZa5IRxf+2FMU1NVK0gEFTsE=; b=Ozrh3JDu1udi+DIl3abou2aRyL0SU8i2KOULtmNL9/sohHX849Yf4J6CpAOD2DyV/3 oZgfFBcVGv/7YNovVvcAEmfqY/CZsN9O9JgixV9k05lrJkwtfVZwXtw/rZNEye+jIXrb maj7+YREZkY1uo+OnhkIID24kKNCivJsivYptRENVcRKmXydmfD8vRnBLrwZ11jMzAZd 3IR6cPRNQgFW/GDwfLtpqvRVya21VOilWUe8jG0VrCvLm/J6hnYTC654INUC8zMLfSJ0 464ECSwPO4z0JCesahkyCBFEFf5DpKoIZvUReEXw9eaCfyEqs0orFfIdX6y1Ilqg99dL dhNQ== X-Gm-Message-State: AKS2vOw6TZWq6EkPRi08ecg57yIt2JIF4WAlo294EZgUjq3y9yvIXD8J eWDAEb/pWmQqGhv2DD7x0w== X-Received: by 10.237.47.98 with SMTP id l89mr15600460qtd.160.1498673789562; Wed, 28 Jun 2017 11:16:29 -0700 (PDT) Received: from [172.16.0.18] ([96.231.216.165]) by smtp.gmail.com with ESMTPSA id r1sm2228142qkh.43.2017.06.28.11.16.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 28 Jun 2017 11:16:28 -0700 (PDT) From: Sean Turner Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Date: Wed, 28 Jun 2017 14:16:27 -0400 References: To: "" In-Reply-To: Message-Id: <699F00F3-FAC6-42AE-99D3-8DE129D18895@sn3rd.com> X-Mailer: Apple Mail (2.3273) Archived-At: Subject: Re: [TLS] IETF 99: request for agenda time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2017 18:16:32 -0000 Just a reminder if you=E2=80=99d like time agenda please let us know. spt > On Jun 6, 2017, at 05:24, Sean Turner wrote: >=20 > All, >=20 > You will have seen the chair's IETF 99 TLS session request on May = 31st. When the session will occur during the week has not yet been set, = but the chairs would still like get a sense of who wants to request = agenda time. The chairs need to upload a draft agenda by 20170705 so if = you would like time on the agenda please submit the request to = tls-chairs@ietf.org by 20160630. Along with your request please let us = know how long you would like. >=20 > J&S From nobody Wed Jun 28 11:34:47 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C23B012EAE1 for ; Wed, 28 Jun 2017 11:34:45 -0700 (PDT) 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 lfZ6SrkYxOwf for ; Wed, 28 Jun 2017 11:34:43 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 2BF3412EAB1 for ; Wed, 28 Jun 2017 11:34:43 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id l21so19521794ywb.1 for ; Wed, 28 Jun 2017 11:34:43 -0700 (PDT) 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=9I+g9Kyq8o2TOWz2nC+0md6v78B98wb9WTIZ1aELoiY=; b=nZD0XxaSIL3A+T4FYgwUT6sSxunM1/2fJLydfyGanuZzPfqTFmnoF2M1GAzvoj1PYk GS4rcoStg0adrwTmTHzcB++B0Gm5KdgOLwj61ulsS37BfkbvFJHca++oI3dYXEQBrv1E /HIo2ddLZTm3fVN9PDUMeNhpVLrlbbo58UekUma+gom6e7lWHV5foatWT1ecrJjoEc3d CWVqBPLlnTCxxzyKXjnYsLm4s8K1KIZJJD3AP9dXqO6Lz4iyfvmVIcrVtZGp9v5CVh1X 0c6mjqfD+BmhOHzlrzPEemfyBhJiljTsyCOrjN0jE3e62AxNr9n2/+7Iy8q5RqZPHfLm D/iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9I+g9Kyq8o2TOWz2nC+0md6v78B98wb9WTIZ1aELoiY=; b=MtvwKhzzgmD9XxEA/214yy3SIuBeCiFmjFW05NILeBkbyo9fDN3iQZc+SBd5CHJP7X zyFYUC/Zaia84AEejb3vGr4jb2kfYdM1s+JZ0pQTVZFJXq6M1mIiec+hvwaoLbgIbRiF SCR5Spt5PnVl3U1QgeQBXk/+Ba0mZFe08B2+8YWEGa9wm1egelOMzIek1qCAbpjG6HE7 BNFYAg6GTAgL1JpE5PjIN10biOYgpgyVW8KbjdbafZVMFKoSO5W5gQWAJ67Ajwsh3bxA PN1Rmqzz/P49zwIDq2No/Ug2W3Z19/7FfX45rzR+gU5ODSlWaN7zbeEPbXNTmafrVupW lA1w== X-Gm-Message-State: AKS2vOzBi4Hk8GDZ2AgQU/laXYcIWtw+NEkEoSiimv3R3VFvkfn89sEp rZzGr76T2UYWYc3N9Ga7rUMV1H8uCjyJDTM= X-Received: by 10.129.146.15 with SMTP id j15mr8729402ywg.283.1498674882378; Wed, 28 Jun 2017 11:34:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Wed, 28 Jun 2017 11:34:01 -0700 (PDT) In-Reply-To: <699F00F3-FAC6-42AE-99D3-8DE129D18895@sn3rd.com> References: <699F00F3-FAC6-42AE-99D3-8DE129D18895@sn3rd.com> From: Eric Rescorla Date: Wed, 28 Jun 2017 11:34:01 -0700 Message-ID: To: Sean Turner Cc: "" Content-Type: multipart/alternative; boundary="94eb2c094216ff8f730553096fbb" Archived-At: Subject: Re: [TLS] IETF 99: request for agenda time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2017 18:34:46 -0000 --94eb2c094216ff8f730553096fbb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I will need 30-45 minutes for DTLS. -Ekr On Wed, Jun 28, 2017 at 11:16 AM, Sean Turner wrote: > Just a reminder if you=E2=80=99d like time agenda please let us know. > > spt > > > On Jun 6, 2017, at 05:24, Sean Turner wrote: > > > > All, > > > > You will have seen the chair's IETF 99 TLS session request on May 31st. > When the session will occur during the week has not yet been set, but the > chairs would still like get a sense of who wants to request agenda time. > The chairs need to upload a draft agenda by 20170705 so if you would like > time on the agenda please submit the request to tls-chairs@ietf.org by > 20160630. Along with your request please let us know how long you would > like. > > > > J&S > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --94eb2c094216ff8f730553096fbb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I will need 30-45 minutes for DTLS.

-Ek= r


On Wed, Jun 28, 2017 at 11:16 AM, Sean Turner = <sean@sn3rd.com&= gt; wrote:
Just a reminder if you= =E2=80=99d like time agenda please let us know.

spt

> On Jun 6, 2017, at 05:24, Sean Turner <sean@sn3rd.com> wrote:
>
> All,
>
> You will have seen the chair's IETF 99 TLS session request on May = 31st.=C2=A0 When the session will occur during the week has not yet been se= t, but the chairs would still like get a sense of who wants to request agen= da time.=C2=A0 The chairs need to upload a draft agenda by 20170705 so if y= ou would like time on the agenda please submit the request to tls-chairs@ietf.org by 20160630.=C2=A0 Along = with your request please let us know how long you would like.
>
> J&S

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

--94eb2c094216ff8f730553096fbb-- From nobody Wed Jun 28 14:16:08 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE17112EC58 for ; Wed, 28 Jun 2017 14:16:07 -0700 (PDT) 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, 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=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 sjX9XxiEYhXW for ; Wed, 28 Jun 2017 14:16:06 -0700 (PDT) Received: from mail-pf0-x22a.google.com (mail-pf0-x22a.google.com [IPv6:2607:f8b0:400e:c00::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 6386212EA6A for ; Wed, 28 Jun 2017 14:16:06 -0700 (PDT) Received: by mail-pf0-x22a.google.com with SMTP id q86so39362381pfl.3 for ; Wed, 28 Jun 2017 14:16:06 -0700 (PDT) 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=VUNmsR3+ozKRFLaTEby70T5YLF1FUSRrG8AdzxWj+VM=; b=edYfX999ODR6rXzpoj3GnBFDtE5SVimwvGuZkNvpveBH6IqJ09lupDXLTCjD9+9LCS ijpcIoJPzdf4XadvnvqthPN6Jq5008Dk6H8GYFavLZKWDer18+nnwqTF28EU1ROl/Amg nrGpLi+9rVZXeLYzi2sOuLmjx582mm0wBUuyXRk0qjm2Rb5N3dyN1y50ttbXDZHAgZRr EkkppyU8tPhGUZMRIXhK74vRFt9HIpBYm4qPwsMqZijFb85qZ4oPs5Sjmeibudf3QNgi dY6E+q0lIjOOa2mVByiljsLiZb4pvNol0bJiP85cuJ3DhMxOq6KRX38UquYZGsDNNBz1 NSUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=VUNmsR3+ozKRFLaTEby70T5YLF1FUSRrG8AdzxWj+VM=; b=aG95DTdamxljQfSPOakYAgDnjo4KOhf4qcxaC4YEe175AO9DyfJuHFr6sfgF32ho5u 3GGN4z/m9a9jVd8BLdQmE3fILcsPOzIRiREJ7RQX8kei4nWwe18y4BPnikwulPWr3Mm5 +c8DROYkJJDDO181Goz3D6uZnYE51p7UggYm2Pu6anIDf3veCZxkOs1/ZcsKj7q42Tnd pr5+QozUdrTRIwMBJdS1D4N54W+SmOxtAhkZSsyMW71KKQCPXzYk2iTCeM7mZOTW97cb wqyzy4xxIJ6lNZvtZe+3xV5XOCSOLEHR/wL7vw8OCXV346oXYY1br5zNWZAGJgkccnVy 4Gdw== X-Gm-Message-State: AKS2vOxs1QyDdfQ66YodbsAG9U25WT+IBh4uvWMlUvReddMiY+aRYZ0M I+e0p71YlzrWr+zPWYMgGxaPcOIayZ1QSoA= X-Received: by 10.84.193.36 with SMTP id e33mr13982398pld.122.1498684565770; Wed, 28 Jun 2017 14:16:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.100.176.233 with HTTP; Wed, 28 Jun 2017 14:15:45 -0700 (PDT) From: Joseph Salowey Date: Wed, 28 Jun 2017 14:15:45 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c188ed42c631c05530bb18a" Archived-At: Subject: [TLS] WGLC: draft-ietf-tls-dnssec-chain-extension-04 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 28 Jun 2017 21:16:08 -0000 --94eb2c188ed42c631c05530bb18a Content-Type: text/plain; charset="UTF-8" This is the working group last call for draft-ietf-tls-dnssec-chain-extension-04. Please send you comments to the list by July 12, 2017. Thanks, J&S --94eb2c188ed42c631c05530bb18a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is the working group= last call for=C2=A0draft-ietf-tls-dnssec-chain-extension-04.=C2=A0 Please sen= d you comments to the list by July 12, 2017. =C2=A0

Thanks,

J&= S
--94eb2c188ed42c631c05530bb18a-- From nobody Thu Jun 29 06:53:01 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 277E4128DF2 for ; Thu, 29 Jun 2017 06:52:59 -0700 (PDT) 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, SPF_PASS=-0.001, URIBL_BLOCKED=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 hmhRlY9NYcfw for ; Thu, 29 Jun 2017 06:52:56 -0700 (PDT) Received: from mx36-42.antispamcloud.com (mx36-42.antispamcloud.com [209.126.121.30]) (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 D547B127868 for ; Thu, 29 Jun 2017 06:52:56 -0700 (PDT) Received: from xsmtp24.mail2web.com ([168.144.250.190] helo=xsmtp04.mail2web.com) by mx36.antispamcloud.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.86) (envelope-from ) id 1dQZsM-0004Xd-VB for tls@ietf.org; Thu, 29 Jun 2017 15:52:55 +0200 Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp04.mail2web.com with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1dQZsL-0007iO-ET for tls@ietf.org; Thu, 29 Jun 2017 09:52:54 -0400 Received: (qmail 13990 invoked from network); 29 Jun 2017 13:52:52 -0000 Received: from unknown (HELO [192.168.1.103]) (Authenticated-user:_huitema@huitema.net@[172.56.42.244]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for ; 29 Jun 2017 13:52:52 -0000 To: Sean Turner , "" References: <699F00F3-FAC6-42AE-99D3-8DE129D18895@sn3rd.com> From: Christian Huitema Message-ID: Date: Thu, 29 Jun 2017 06:52:50 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <699F00F3-FAC6-42AE-99D3-8DE129D18895@sn3rd.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Originating-IP: 168.144.250.190 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: ham X-SpamExperts-Outgoing-Evidence: Combined (0.06) X-Recommended-Action: accept X-Filter-ID: PqwsvolAWURa0gwxuN3S5YEa3T7JuZT23fGO2rGt3ZgTCGhDnudOJ80D1c8rffxrus7BTv7Ss8cH d2IQQuvdbtM+m4WpRRDP6YzwkAPgQJYoNzrMVvavOgy+9M5kGys4ND46yZLY9QyX+cRXmooQ3hum JwiT+2brWmQlzkLIcXivpIH4ag6BM/+u9ym+BA23tPln4dXw7YpwrdrzWM8qBpzZ8rfsXcrYidfw YfZGgWImPKPN84dXMnszeUnKbkfvYOEkjsX7F8KmpUaZQHV+ScWIfGf9Fu8q9UhMPe0GR5O2G5Pj 7iQJEmtNUzH3idZ6uMF2OhyCCCV83x+RZrKIj0QqMGQOSwmEPwP4wBzM77N8GvkYGGDFjg9NrmGY yNnXsSjdYwfRhjHqxQXDsBKLpKs+iZ7+uSas6Kaz0EAgJQD6lO4FGen962xgCFRckncKfg1XSK9P 1z/R6plfrFWGyWactxkZk5v2QrJuQdpnovfeNHk15VolAGHS5rCXQKDym+Gab6cuAPzLi/SdAxlO dgkraHgbbAuZgv0Q6mJ3vUcipz1IT62ZEk6+MmovaufbiR3bHfnMCIEU+nrglojKwMr3vOY18GvB wSXAfWcj236N2IVdgBdepwvDBBcDOz9LNdSMuNhZC3X/nGdDKYyg+xII1yJ8udUSd8siDlV+9cBL pGLKbiMLMKI7KIsgfDrl6J1fhOzjF0b4LXcjJZ5lorSoCYRNcdNYFM9Dkt7piwO7IVXITpPh1qZI 46Rz116s/WLxCXuXszKymQev9OOX319e6qt4y0llDRDaFA2tZcPw1eMmeklA3MQEw0NwP6IDPa8Q GWJY81iEsidlXaP4/sbpzuwjGHyC+YDvAYilEDNpxNDZdajQS3WSizkDbMOPTRpUChnn7dZMk3sz 8NLrGw== X-Report-Abuse-To: spam@quarantine5.antispamcloud.com Archived-At: Subject: Re: [TLS] IETF 99: request for agenda time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2017 13:52:59 -0000 On 6/28/2017 11:16 AM, Sean Turner wrote: > Just a reminder if you’d like time agenda please let us know. > Can we get a slot to discuss SNI encryption (https://datatracker.ietf.org/doc/draft-huitema-tls-sni-encryption/)? -- Christian Huitema From nobody Thu Jun 29 11:26:21 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3162A127867 for ; Thu, 29 Jun 2017 11:26:20 -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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=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 Fu33PJBu6BXh for ; Thu, 29 Jun 2017 11:26:18 -0700 (PDT) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::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 1D813126B7E for ; Thu, 29 Jun 2017 11:17:43 -0700 (PDT) Received: by mail-lf0-x22a.google.com with SMTP id b207so57564081lfg.2 for ; Thu, 29 Jun 2017 11:17:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=W4+6wMX+L57obhq01dyQIOf4lZfE3pcEhmPBjHxVJS8=; b=IU27+MTOifkDRzmJZxYWZThaTC8V00Tcm1b4X2MlnbzipAmMnD3VRBJQna7VumVv2o Qb/XCGi/mfeN/P9dk21YNAOvSDUAFg1/uZFwPNzW1ob/ZoFg1WOZKoK2rRHD/t7bhkQI O7wsi9+fG2Cvr1Epvvo2WqYDXyL2L5NqBjP+AvXdh7eyOeYQiP7Q6dhWTKAFma08TwSu Ap8Fut7G+YdSSIGLPa+L796ApnRaglHIEAEr2IlXfrNXdKearuHmD8oUtLXNDt/zeuJq ZLtU56B8Nm8qfQr3XNmTopRlLbd26It/vv0cAAaSnEgb+JvNIu2B3Rj1nCJzSgLzob0j Js4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=W4+6wMX+L57obhq01dyQIOf4lZfE3pcEhmPBjHxVJS8=; b=f7G4sOxNPBSHj958Gvx92TlbhFTp++20NN91yrgfLCJEgBv3r71hBi0STsNUBDg6AA sebPZFNu5W2WKOLObz3uuOuIwhK3FzM5HgfLAiIAN4ws2SxpuAOdQorNylEcov2PSgDz GFPbhTUCPRUsnu8C7SsPE/MjrN4cJyy2sFjzOwEig6UX1FlmxnUX5DatBYEgF2NchYGr cQoy5riGG3FMpXU7KOcXWJS+Jflvd59LCFbG75I9dpla3I8U3IZfu5EnFv/02JX4Z4P8 xuhnpUcuVk34B90oDdRRGibItkvB+j1exniQut1Tj9ZeGGa9EUiT7WruIYazeCMu5DiJ rsHA== X-Gm-Message-State: AKS2vOwogperswZajgEUAOCbk5Ay/dOs7TeY6Wp5YbId8bpOOFiIMqXy oCPbgoiKxHMOMmZZeZimyZscJbizYlDmPqA= X-Received: by 10.46.77.70 with SMTP id a67mr5685215ljb.103.1498760261397; Thu, 29 Jun 2017 11:17:41 -0700 (PDT) MIME-Version: 1.0 Received: by 10.46.78.17 with HTTP; Thu, 29 Jun 2017 11:17:40 -0700 (PDT) In-Reply-To: References: From: Martin Thomson Date: Thu, 29 Jun 2017 11:17:40 -0700 Message-ID: To: Sean Turner Cc: "" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [TLS] IETF 99: request for agenda time X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2017 18:26:20 -0000 I don't need time for the test vectors (I'll update the draft, but it's just not that interesting to talk about). I would like time for https://tools.ietf.org/html/draft-thomson-tls-record-limit-00 though. On 6 June 2017 at 02:24, Sean Turner wrote: > All, > > You will have seen the chair's IETF 99 TLS session request on May 31st. = When the session will occur during the week has not yet been set, but the c= hairs would still like get a sense of who wants to request agenda time. Th= e chairs need to upload a draft agenda by 20170705 so if you would like tim= e on the agenda please submit the request to tls-chairs@ietf.org by 2016063= 0. Along with your request please let us know how long you would like. > > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Jun 29 13:52:09 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8B2129AD5 for ; Thu, 29 Jun 2017 13:52:07 -0700 (PDT) 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, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=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 11L0CRF7Ze7a for ; Thu, 29 Jun 2017 13:52:00 -0700 (PDT) Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002: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 9C3E412EAC4 for ; Thu, 29 Jun 2017 13:52:00 -0700 (PDT) Received: by mail-yw0-x234.google.com with SMTP id j11so41930155ywa.2 for ; Thu, 29 Jun 2017 13:52:00 -0700 (PDT) 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=uaI6FTB+kG/hPpmFj6srg8MTQRZHG+c8e2dkKZGF+vk=; b=PDfiAnoMQ2GaOXlhmdP/FbkOgWknsee/Oxh8xtNAX86BoR3NU1VX5vJNPNLO0ZpvZ+ Lx1turw+v201l9HdT4UuKG8eVkD1Qf4to9QayheOwsrRfFDhDfN9TixXTFpUnP/maP5K /XsuH25b+AObB0yevScZs/zE6hUzyP3nh7qOyPF5/gsSMIu7bt/uIOhkfvndyLR9a/tC qvF2GTg1s2mNBh8icozGIM4Zi2xkX3kvpDPK1NPLidW500KT/wZSxxxbyLXi60IRskF2 sObSGB+g5Qa3URxBxDCZthO6mC0D7zskgIza2bNWwU3TasgGlvPLwwsXDvJinZEJdUEk VByQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=uaI6FTB+kG/hPpmFj6srg8MTQRZHG+c8e2dkKZGF+vk=; b=nSCsCNcltPHgsKhEkGzwIFdfbiRrWvWQX6nt1DlBiVnNNe81UritjiTFk/VuYtCx0E nJNuEZ5IJWdG3ucKXQR6HoIrnW7h4/8B3Z9PvrsSKlfUl+glxVzeO+cfj6BIWkFA0NiD iDs2fCynzPVRowMYcTTDYxNyLb1L/M+Wc7r5Ol7ZT+ipZ/wfO3f4YJ3JH5KJMwcfHsq8 Ojxb9gYpP0kJ5KAP7Qx1BIfmejnx5krvV8wgg0OmyuWPvFBHVrQFwhdpxRiU85RjHiW0 U2EdAYRbdCDvBGZK6ZJqTzrR+Obp1HYzOzg3iZqZ9V5t071L5fETC9Y1x+P8+4Ph/U+e xL0Q== X-Gm-Message-State: AKS2vOy++V7N8Um9Qb9++dRFDrSziWxXeXJ2L9sEwKwthLmgb63FFAW6 9S1kfP20bqWeMmfap2sZX5aFPTLntu73 X-Received: by 10.13.252.194 with SMTP id m185mr13338304ywf.85.1498769519943; Thu, 29 Jun 2017 13:51:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Thu, 29 Jun 2017 13:51:19 -0700 (PDT) In-Reply-To: <20170627184907.oollf5evznyek5tg@LK-Perkele-VII> References: <20170613205113.GA13223@LK-Perkele-V2.elisa-laajakaista.fi> <20170614174531.GA17930@LK-Perkele-V2.elisa-laajakaista.fi> <20170624052727.26n4spscu77nlnlw@LK-Perkele-VII> <20170626064320.aguxkeikwdfhpnk5@LK-Perkele-VII> <20170627184907.oollf5evznyek5tg@LK-Perkele-VII> From: Eric Rescorla Date: Thu, 29 Jun 2017 13:51:19 -0700 Message-ID: To: Ilari Liusvaara Cc: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= , "tls@ietf.org" Content-Type: multipart/alternative; boundary="94eb2c08d810d63b1005531f78a8" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2017 20:52:07 -0000 --94eb2c08d810d63b1005531f78a8 Content-Type: text/plain; charset="UTF-8" On Tue, Jun 27, 2017 at 11:49 AM, Ilari Liusvaara wrote: > On Mon, Jun 26, 2017 at 11:16:02AM -0700, Eric Rescorla wrote: > > OK, I'll move this out of the "if you can do a lot of replays" section > > > > Another thing: > > The PR briefly mentions to be careful with 0-RTT exporters, but nothing > concrete-looking. > > > If 0-RTT data is replayed and the replay accepted, all replays share the > same 0-RTT exporter values. This causes two kinds of problems: > > 1) If 0-RTT exporters are used for authentication, then an attacker > in possession of resumption secret and DHE key (if any) can replay the > generated tokens to another connection with replayed 0-RTT, even > without the better-protected authentication key. > I think this mostly belongs with the token binding spec, but I added a little bit here. 2) If 0-RTT exporters are used for key material for to-client > direction, then the replays will have the same keying material, which > is highly dangerous with many encryption algorithms. > Right. One should not do this. I added text. -Ekr > > > -Ilari > --94eb2c08d810d63b1005531f78a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Jun 27, 2017 at 11:49 AM, Ilari Liusvaara <ilariliusvaara@welho.com> wrote:
2) If 0-RTT exporters are used for key material for to-client
direction, then the replays will have the same keying material, which
is highly dangerous with many encryption algorithms.
<= br>
Right. One should not do this. I added text.

-Ekr




-Ilari

--94eb2c08d810d63b1005531f78a8-- From nobody Thu Jun 29 13:54:18 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77F0312EAC4 for ; Thu, 29 Jun 2017 13:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 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, URIBL_BLOCKED=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 zXoSpNzdsIEI for ; Thu, 29 Jun 2017 13:54:14 -0700 (PDT) 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 C2007129AD5 for ; Thu, 29 Jun 2017 13:54:14 -0700 (PDT) Received: by mail-yb0-x22a.google.com with SMTP id v197so6753714ybv.3 for ; Thu, 29 Jun 2017 13:54:14 -0700 (PDT) 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=YeeUbSOv1zcOYe9yRrDLtEWdeF72WxQSV2M9qSYU4oA=; b=a5i9wevtHoi37JwCeTNQkHUnd7EZyF2weM2lSY1ucclZF8EuaTMM7ufKWJLSTH6fRh p05Ar33KOuF9n2IFJD5m9YuiYP0DYzKLB7EXiMlTcmsE1//0duOG5pinqoIDtpMgXH1w RnRATqKRFKmZkfoMnUyW8CevFG6kemj09bBId3PFJMaj0q5YEZn5FzGi5brOYCmE6Z1n BOSpzdxO8sbcWo1y3wg7DdYuDVcVP+jqDhWvmn50pwbZ3VjBQdBFtTO0iSfMM/Vw41Rh nSq4mRdrxgZDxHHABhfzUSLQPDwwuun24wgemvfE9aXnR6ZzSMeNSgni+oaBnXV9bB2v GFFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=YeeUbSOv1zcOYe9yRrDLtEWdeF72WxQSV2M9qSYU4oA=; b=ayie7H5uDxmjLwDDHaohOtbAUH2YSFDiLRUL6vqhie0L6WdsE6DC6KBUL6OdosIAp4 tuG4Tth24LUGuFGACZtox4FY1X6VfSvbr1okBvjTMaj+YfauI/xAEST3Nv/j/vZ4D4ix HAkhGH2RDh4zDj16DPuDHxSCvQswg9ArH51PyENp0FmDkaiQXwhBev4jBg9NAIFfMPOz Pkt+jIQ/3/h4mBhpBClidD+oHEC4ncKdNaN3aQvruE86X/f85ePQg52gWPw+Z1aXGHxp 7f35zboAAzD7KfXYPMgYsYcScwa9A1nNij1RoqxxqMgrsLExr0pyUtuw6v5qWHaDDQF/ E6Og== X-Gm-Message-State: AKS2vOx73kjp+zRTVemjnTqmE95MaMnwSFSHQKVXOutv6S/71tldDxLC U4vD0RnY9iVgmmjl7U+4gB8ltLKGDkUjSnA= X-Received: by 10.37.68.87 with SMTP id r84mr14296802yba.229.1498769653189; Thu, 29 Jun 2017 13:54:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Thu, 29 Jun 2017 13:53:32 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Thu, 29 Jun 2017 13:53:32 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a113f5f3ec7cafe05531f80eb" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 29 Jun 2017 20:54:16 -0000 --001a113f5f3ec7cafe05531f80eb Content-Type: text/plain; charset="UTF-8" I have updated the PR to match people's comments. I would like to merge this soon, so please get any final comments in. -Ekr On Sun, Jun 11, 2017 at 8:18 AM, Eric Rescorla wrote: > Hi folks, > > We've had a phenomenal amount of discussion around 0-RTT anti-replay, > and based on my recent summary e-mails I think we generally agree > about the technical facts, so it's time to finalize the PR and land it > in the specification. > > > Here's what I propose to do: > > - Describe the attacks that Colm described. > > - Distinguish between replay and retransmission > > - Mandate (SHOULD-level) that servers do some sort of bounded > (at-most-N times) anti-replay mechanism and emphasize that > implementations that forbid replays entirely (only allowing > retransmission) are superior. > > - Describe the stateless mechanism as a recommended behavior but not > as a substitute for the other mechanisms. As Martin Thomson has > pointed out, it's a nice pre-filter for either of these other > mechanisms. > > - Clarify the behavior you need to get PFS. > > - Require (MUST) that clients only send and servers only accept "safe" > requests in 0-RTT, but allow implementations to determine what is > safe. > > Note: there's been a lot of debate about exactly where this stuff > should go in the document and how it should be phrased. I think these > are editorial questions and so largely my discretion. > > > Here's what I do not intend to do. > > - Mandate (MUST-level) any anti-replay mechanism. I do not believe > there is any WG consensus for this. > > - Design a mechanism to allow the server to tell the client that it > either (a) enforces strong anti-replay or (b) deletes PSKs after > first use. Either of these seem like OK ideas, but they can be added > to NST as extensions at some future time, and I haven't seen a lot > of evidence that existing clients would consume these. > > I recognize that nobody will be entirely happy with this, but I > believe it most closely represents consensus. Assuming the chairs > agree, I'd like to suggest a brief period of discussion on this > proposal, followed by a consensus call, and then I'll generate a PR > that enacts it. People will still have time to review that, but in > order to avoid an endless round of dicussion, the idea will be able to > review it for conformance to these principles, not to re-litigate > these. > > -Ekr > > > > > > > > > > > > > > --001a113f5f3ec7cafe05531f80eb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I have updated the PR to match people's comments. I wo= uld like to merge this soon, so please get any final comments in.

<= /div>
-Ekr


On Sun, Jun 11, 2017 at 8:18 AM, Eric Rescorla <ekr@rtf= m.com> wrote:
Hi folks,

We've had a phenomenal amou= nt of discussion around 0-RTT anti-replay,
and based on my recent= summary e-mails I think we generally agree
about the technical f= acts, so it's time to finalize the PR and land it
in the spec= ification.


Here's what I propos= e to do:

- Describe the attacks that Colm describe= d.

- Distinguish between replay and retransmission=

- Mandate (SHOULD-level) that servers do some sor= t of bounded
=C2=A0 (at-most-N times) anti-replay mechanism and e= mphasize that
=C2=A0 implementations that forbid replays entirely= (only allowing
=C2=A0 retransmission) are superior.
- Describe the stateless mechanism as a recommended behavior b= ut not
=C2=A0 as a substitute for the other mechanisms. As Martin= Thomson has
=C2=A0 pointed out, it's a nice pre-filter for e= ither of these other
=C2=A0 mechanisms.

= - Clarify the behavior you need to get PFS.

- Requ= ire (MUST) that clients only send and servers only accept "safe"<= /div>
=C2=A0 requests in 0-RTT, but allow implementations to determine = what is
=C2=A0 safe.

Note: there's b= een a lot of debate about exactly where this stuff
should go in t= he document and how it should be phrased.=C2=A0 I think these
are= editorial questions and so largely my discretion.


Here's what I do not intend to do.

=
- Mandate (MUST-level) any anti-replay mechanism. I do not believe
=C2=A0 there is any WG consensus for this.

= - Design a mechanism to allow the server to tell the client that it
=C2=A0 either (a) enforces strong anti-replay or (b) deletes PSKs after<= /div>
=C2=A0 first use. Either of these seem like OK ideas, but they ca= n be added
=C2=A0 to NST as extensions at some future time, and I= haven't seen a lot
=C2=A0 of evidence that existing clients = would consume these.

I recognize that nobody will = be entirely happy with this, but I
believe it most closely repres= ents consensus. Assuming the chairs
agree, I'd like to sugges= t a brief period of discussion on this
proposal, followed by a co= nsensus call, and then I'll generate a PR
that enacts it. Peo= ple will still have time to review that, but in
order to avoid an= endless round of dicussion, the idea will be able to
review it f= or conformance to these principles, not to re-litigate
these.

-Ekr


=C2=A0= =C2=A0
=C2=A0=C2=A0



<= /div>




=C2= =A0 =C2=A0 =C2=A0=C2=A0


--001a113f5f3ec7cafe05531f80eb-- From nobody Fri Jun 30 09:32:59 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50BD112ECF5 for ; Fri, 30 Jun 2017 09:32:57 -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 (2048-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 CZOcWTXeTbZS for ; Fri, 30 Jun 2017 09:32:55 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 78682126557 for ; Fri, 30 Jun 2017 09:32:55 -0700 (PDT) Received: from pps.filterd (m0050093.ppops.net [127.0.0.1]) by m0050093.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5UGVdhZ032049; Fri, 30 Jun 2017 17:32:55 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : cc : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=5swIivWV98wmWR9fIjcCEY50U5fGuc5eztuY9fj/ZXw=; b=NRbQrNQfaYE24vY3s3wq7tgnQFDUflewbGr24C4MYIeX6cb3ZkQGIJDMdUb+d355K/bx lFl9cPhHmSggP4JxDv2Ilq1ScDkgpdZj9Pydjs+OlP2VvWCtAFagOCOmyOfTSkjXS7uV jN8c5AWgPy3Z2S2AL77LgKb6gUASuuXYQz2Xb/S/F2f0rw4YRLQrQlxE4aVopYf/Orms qbX8ULgX7/W/HKlT2euhQcUJ3A//uYSAwdrPcHTVduBf//+jA4EM/iwLk8hVIusp4ybd JFeXKLkqYxEumYm/ks7Ruj+Rozp2Ke0sBgcR274N9cET8EA8HmWXgszIfcePzHjee+wg nA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050093.ppops.net-00190b01. with ESMTP id 2bdcefu16g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Jun 2017 17:32:54 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5UGVD6M031518; Fri, 30 Jun 2017 12:32:53 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b9kdv4r1v-1; Fri, 30 Jun 2017 12:32:52 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id 5F89020067; Fri, 30 Jun 2017 10:32:52 -0600 (MDT) To: Eric Rescorla , "tls@ietf.org" References: From: Benjamin Kaduk Cc: "Nygren, Erik" Message-ID: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> Date: Fri, 30 Jun 2017 11:32:51 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1F02A1643D5CC6128B6FA1BA" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300260 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300257 Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2017 16:32:57 -0000 This is a multi-part message in MIME format. --------------1F02A1643D5CC6128B6FA1BA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/29/2017 03:53 PM, Eric Rescorla wrote: > I have updated the PR to match people's comments. I would like to > merge this soon, so please get any final comments in. I made a couple comments on the PR that are more appropriate for the list, so I'll repeat them here and hopefully get replies from the broader audience. First off, I think we should MUST-level require servers to implement a hard limit on the number of replays accepted. However, it doesn't quite seem realistic to require "MUST use either [single-use tickets] or [ClientHello recording]". My preference would be "MUST use either [single-use tickets], [ClientHello recording], or equivalently strong protection", but I don't know what level of support we have for such a strong requirement. As an alternative, I will also put out "MUST limit replays to at most the number of endpoints capable of accepting connections for a given identity, and SHOULD provide even stronger replay protections, such as [single-use tickets] or [ClientHello recording]." I think we have general agreement that strong anti-replay as described in the document is feasible for a single-server deployment, and this last formulation is achievable in multi-server environments by just giving each server its own local per-server protection. (My main reason for wanting a MUST-level hard cap is that I worry that millions/billions of replays will have really nasty consequences in terms of DoS and side channel issues.) But, this has been quite a long thread spread out over multiple forums/email subjects, so I've also probably forgotten some of the arguments presented against having MUST-level strong anti-replay requirements; I'd greatly appreciate if someone could repeat them here for everyone's consideration. The pull request also has some text: +If the expected arrival time is in the window, then the server +checks to see if it has recorded a matching ClientHello. It +either aborts the handshake with an "illegal_parameter" alert +or accepts the PSK but reject 0-RTT. If no matching ClientHello +is found, then it accepts 0-RTT and then stores the ClientHello for +as long as the expected_arrival_time is inside the window. +Servers MAY also implement data stores with false positives, such as +Bloom filters, in which case they MUST respond to apparent replay by +rejecting 0-RTT but MUST NOT abort the handshake. I am not sure why we are giving servers a choice between aborting and accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), especially not without giving guidance as to why they might choose one or the other. My natural inclination would be to have the expected behavior be to abort and only fall back to the other behavior if using a scheme with false positives, but Ekr thinks Erik Nygren was in support of just continuing on with 1-RTT. It looks like this was https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 , where I ... took the opposite position from what I just said my "natural inclination" was, amusingly enough. But still, why does this need to be a choice? Rejecting 0-RTT and continuing on to 1-RTT seems like it would be reasonable in all the cases mentioned so far. -Ben --------------1F02A1643D5CC6128B6FA1BA Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/29/2017 03:53 PM, Eric Rescorla wrote:
I have updated the PR to match people's comments. I would like to merge this soon, so please get any final comments in.

I made a couple comments on the PR that are more appropriate for the list, so I'll repeat them here and hopefully get replies from the broader audience.


First off, I think we should MUST-level require servers to implement a hard limit on the number of replays accepted.  However, it doesn't quite seem realistic to require "MUST use either [single-use tickets] or [ClientHello recording]".  My preference would be "MUST use either [single-use tickets], [ClientHello recording], or equivalently strong protection", but I don't know what level of support we have for such a strong requirement.  As an alternative, I will also put out "MUST limit replays to at most the number of endpoints capable of accepting connections for a given identity, and SHOULD provide even stronger replay protections, such as [single-use tickets] or [ClientHello recording]."  I think we have general agreement that strong anti-replay as described in the document is feasible for a single-server deployment, and this last formulation is achievable in multi-server environments by just giving each server its own local per-server protection.  (My main reason for wanting a MUST-level hard cap is that I worry that millions/billions of replays will have really nasty consequences in terms of DoS and side channel issues.)

But, this has been quite a long thread spread out over multiple forums/email subjects, so I've also probably forgotten some of the arguments presented against having MUST-level strong anti-replay requirements; I'd greatly appreciate if someone could repeat them here for everyone's consideration.


The pull request also has some text:

+If the expected arrival time is in the window, then the server
+checks to see if it has recorded a matching ClientHello. It
+either aborts the handshake with an "illegal_parameter" alert
+or accepts the PSK but reject 0-RTT. If no matching ClientHello
+is found, then it accepts 0-RTT and then stores the ClientHello for
+as long as the expected_arrival_time is inside the window.
+Servers MAY also implement data stores with false positives, such as
+Bloom filters, in which case they MUST respond to apparent replay by
+rejecting 0-RTT but MUST NOT abort the handshake.

I am not sure why we are giving servers a choice between aborting and accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), especially not without giving guidance as to why they might choose one or the other.  My natural inclination would be to have the expected behavior be to abort and only fall back to the other behavior if using a scheme with false positives, but Ekr thinks Erik Nygren was in support of just continuing on with 1-RTT.  It looks like this was https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 , where I ... took the opposite position from what I just said my "natural inclination" was, amusingly enough.  But still, why does this need to be a choice?  Rejecting 0-RTT and continuing on to 1-RTT seems like it would be reasonable in all the cases mentioned so far.

-Ben
--------------1F02A1643D5CC6128B6FA1BA-- From nobody Fri Jun 30 09:54:15 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86A75130A92 for ; Fri, 30 Jun 2017 09:54:13 -0700 (PDT) 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 I56Cl1m8dCGy for ; Fri, 30 Jun 2017 09:54:10 -0700 (PDT) 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 A297D12ECF5 for ; Fri, 30 Jun 2017 09:54:10 -0700 (PDT) Received: by mail-yw0-x236.google.com with SMTP id j11so51496250ywa.2 for ; Fri, 30 Jun 2017 09:54:10 -0700 (PDT) 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=wKjVcIEczeLxNCx3uURSSzZHF3UMEoLjlYjW3XtvmAI=; b=bdpDANCCzz/PzWPFggdlyZ2a+HReEM0VQXW1DrEYjvXYofAPYCSzrU/gAowr9Azk4T V3Xt630/uMKuF+dwgz1GbxeydAlhZg0xK+LMPeecLwPbSyAZDvg/XsSIcmGQPDM2drJP qnp/XKYqXc8g+2clzQ7jYeo4xQ+cy5e4YFqUdHcMVzPYV3L8ypT6xoXmIsoHbBTzxx14 5ER4dY+FKwn0hcYZeFzPGTHRohQDsr+43y4sKQMA8hGJp+G8/GlVu+SZZErJG4uYfyd7 pGs1xL8du+bw9tONTlO3GLfECcvelsOer2D2pydOOjMswH4GyJzG8S2KtacOzvpVAhK3 Kjvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wKjVcIEczeLxNCx3uURSSzZHF3UMEoLjlYjW3XtvmAI=; b=cvPlexIAeYHjDhxhYPptgmKAGIIsc7/qan+rRtNVHOLOHPu0dkjNCumA5iTz6MCbl7 OB6CMrbVoqmFCEtsALqTXQ0MBoIeN3vPowucCEXXqa1wptX4R22UaN5/JDw8JlG+bh4h UBbtv31cQ2vP9d+52/dxylt3+M6zM0cAdfWIAA1itAlkenpHd04uvRVh9snXnbPWQXtD 48NtqaYcMGS9ToSaXOHhvfzf6UI2QTHFOY9YAD5U4KyNK6++E3iLaOPhUUzPDkFVzq3d TPUyuIPlMIZg9BwOaHqO+GYenkmualkalJdPnbgcpUhxhN6gkVQbXL6boDMdUDdN0QbI /i0Q== X-Gm-Message-State: AKS2vOx1AvgCNvE1YDHNRKw9oi43KmJeSYamiFIVLa7SK46WLsXQqNRR iRQoo6r2kaVu/gWXiiaF1T83t6AjNTfW X-Received: by 10.129.109.206 with SMTP id i197mr10476222ywc.24.1498841649858; Fri, 30 Jun 2017 09:54:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Fri, 30 Jun 2017 09:53:29 -0700 (PDT) In-Reply-To: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> References: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> From: Eric Rescorla Date: Fri, 30 Jun 2017 09:53:29 -0700 Message-ID: To: Benjamin Kaduk Cc: "tls@ietf.org" , "Nygren, Erik" Content-Type: multipart/alternative; boundary="001a114dd2661d74da0553304439" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2017 16:54:13 -0000 --001a114dd2661d74da0553304439 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk wrote: > On 06/29/2017 03:53 PM, Eric Rescorla wrote: > > I have updated the PR to match people's comments. I would like to merge > this soon, so please get any final comments in. > > > I made a couple comments on the PR that are more appropriate for the list, > so I'll repeat them here and hopefully get replies from the broader > audience. > > > First off, I think we should MUST-level require servers to implement a > hard limit on the number of replays accepted. However, it doesn't quite > seem realistic to require "MUST use either [single-use tickets] or > [ClientHello recording]". My preference would be "MUST use either > [single-use tickets], [ClientHello recording], or equivalently strong > protection", but I don't know what level of support we have for such a > strong requirement. As an alternative, I will also put out "MUST limit > replays to at most the number of endpoints capable of accepting connections > for a given identity, and SHOULD provide even stronger replay protections, > such as [single-use tickets] or [ClientHello recording]." I think we have > general agreement that strong anti-replay as described in the document is > feasible for a single-server deployment, and this last formulation is > achievable in multi-server environments by just giving each server its own > local per-server protection. (My main reason for wanting a MUST-level hard > cap is that I worry that millions/billions of replays will have really > nasty consequences in terms of DoS and side channel issues.) > > But, this has been quite a long thread spread out over multiple > forums/email subjects, so I've also probably forgotten some of the > arguments presented against having MUST-level strong anti-replay > requirements; I'd greatly appreciate if someone could repeat them here for > everyone's consideration. > > > The pull request also has some text: > > +If the expected arrival time is in the window, then the server > +checks to see if it has recorded a matching ClientHello. It > +either aborts the handshake with an "illegal_parameter" alert > +or accepts the PSK but reject 0-RTT. If no matching ClientHello > +is found, then it accepts 0-RTT and then stores the ClientHello for > +as long as the expected_arrival_time is inside the window. > +Servers MAY also implement data stores with false positives, such as > +Bloom filters, in which case they MUST respond to apparent replay by > +rejecting 0-RTT but MUST NOT abort the handshake. > > I am not sure why we are giving servers a choice between aborting and > accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), > especially not without giving guidance as to why they might choose one or > the other. My natural inclination would be to have the expected behavior > be to abort and only fall back to the other behavior if using a scheme with > false positives, but Ekr thinks Erik Nygren was in support of just > continuing on with 1-RTT. It looks like this was > https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 , > where I ... took the opposite position from what I just said my "natural > inclination" was, amusingly enough. But still, why does this need to be a > choice? Rejecting 0-RTT and continuing on to 1-RTT seems like it would be > reasonable in all the cases mentioned so far. > Well, my reason for not wanting to do that is that it's a clear replay and so should be a hard failure. So, I'd be happy to mandate abort the handshake, but if we can't agree on that, I'd rather have a choice. -Ekr --001a114dd2661d74da0553304439 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

= On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <bkaduk@akamai.com>= wrote:
=20 =20 =20
On 06/29/2017 03:53 PM, Eric Rescorla wrote:
=20
I have updated the PR to match people's comments= . I would like to merge this soon, so please get any final comments in.

 I made a couple comments on the PR that are more appropriate for the list, so I'll repeat them here and hopefully get replies from the broader audience.


First off, I think we should MUST-level require servers to implement a hard limit on the number of replays accepted.=C2=A0 However, it doesn= 't quite seem realistic to require "MUST use either [single-use tickets] or [ClientHello recording]".=C2=A0 My preference would be= "MUST use either [single-use tickets], [ClientHello recording], or equivalently strong protection", but I don't know what level o= f support we have for such a strong requirement.=C2=A0 As an alternative,= I will also put out "MUST limit replays to at most the number of endpoints capable of accepting connections for a given identity, and SHOULD provide even stronger replay protections, such as [single-use tickets] or [ClientHello recording]."=C2=A0 I think we have genera= l agreement that strong anti-replay as described in the document is feasible for a single-server deployment, and this last formulation is achievable in multi-server environments by just giving each server its own local per-server protection.=C2=A0 (My main reason for wanting a MUST-level hard cap is that I worry that millions/billions of replays will have really nasty consequences in terms of DoS and side channel issues.)

But, this has been quite a long thread spread out over multiple forums/email subjects, so I've also probably forgotten some of the arguments presented against having MUST-level strong anti-replay requirements; I'd greatly appreciate if someone could repeat them here for everyone's consideration.


The pull request also has some text:

+If the expected arrival time is in the window, then the server
+checks to see if it has recorded a matching ClientHello. It
+either aborts the handshake with an "illegal_parameter" aler= t
+or accepts the PSK but reject 0-RTT. If no matching ClientHello
+is found, then it accepts 0-RTT and then stores the ClientHello for +as long as the expected_arrival_time is inside the window.
+Servers MAY also implement data stores with false positives, such as
+Bloom filters, in which case they MUST respond to apparent replay by
+rejecting 0-RTT but MUST NOT abort the handshake.

I am not sure why we are giving servers a choice between aborting and accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), especially not without giving guidance as to why they might choose one or the other.=C2=A0 My natural inclination would be to have the expected behavior be to abort and only fall back to the other behavior if using a scheme with false positives, but Ekr thinks Erik Nygren was in support of just continuing on with 1-RTT.=C2= =A0 It looks like this was https://github.com/tlswg/tls13-spec/pull/1005#discussion_r11= 4924733 , where I ... took the opposite position from what I just said my "natural inclination" was, amusingly enough.=C2=A0 But still,= why does this need to be a choice?=C2=A0 Rejecting 0-RTT and continuing on to 1-RTT seems like it would be reasonable in all the cases mentioned so far.

Well, my reason for n= ot wanting to do that is that it's a clear replay and so should
be a hard failure. So, I'd be happy to mandate abort the handshake, = but if we can't
agree on that, I'd rather have a choice.<= /div>

-Ekr

--001a114dd2661d74da0553304439-- From nobody Fri Jun 30 10:00:23 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60F11131442 for ; Fri, 30 Jun 2017 10:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.011 X-Spam-Level: X-Spam-Status: No, score=-0.011 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, HTTPS_HTTP_MISMATCH=1.989, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 yGLbE4Fk2b79 for ; Fri, 30 Jun 2017 10:00:19 -0700 (PDT) Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::1]) (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 7815A129B10 for ; Fri, 30 Jun 2017 10:00:19 -0700 (PDT) Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.21/8.16.0.21) with SMTP id v5UGvaBL032624; Fri, 30 Jun 2017 18:00:15 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=jMdx1ZeuB7dAMnSiqftuKsAY0B2ZuFQ1h26c3T6QqI8=; b=mzWTwPFkK17tOuNX+M9CHnVTBzP9h5Cn42PMBDl5S//IXNwfSBAqADNiKg9Pyl9JV8c1 plNqlN+0Rx2+gDM+B6I75mEL47gfcz3UriTdDWgPhsjMMVK5Ivp/3YqyToR1SBLWz8oX PKJC/TxSUdIslG0+S4pPw95spSqDs6JdGXLkidYrdBWYvjDBRj2yU27Fh/EsfMzFgzWb i18bQctLl9YxOrGtd2P4a8OTR6LH99Zbe8VpEJDPKFMErbQdB5Z0WwXf5jcHQRi0cq2z fp1d2JTyvC5YJbkJEO9X+SGmSojp3ODR70BRs0PiQkdtKmFemYJluBI5WM0QxIoA6liO yA== Received: from prod-mail-ppoint4 ([96.6.114.87]) by m0050096.ppops.net-00190b01. with ESMTP id 2bd3nyp89f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Jun 2017 18:00:06 +0100 Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.17/8.16.0.17) with SMTP id v5UGtcaY015944; Fri, 30 Jun 2017 13:00:00 -0400 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint4.akamai.com with ESMTP id 2b9kdv4tp9-1; Fri, 30 Jun 2017 13:00:00 -0400 Received: from [172.19.17.86] (bos-lpczi.kendall.corp.akamai.com [172.19.17.86]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id DF85E20068; Fri, 30 Jun 2017 10:59:59 -0600 (MDT) To: Eric Rescorla Cc: "tls@ietf.org" , "Nygren, Erik" References: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> From: Benjamin Kaduk Message-ID: <983f5c59-47a1-af05-bf4c-146d68a617a5@akamai.com> Date: Fri, 30 Jun 2017 11:59:59 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------616DF0D5FFD8046B94A0BE41" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300266 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-06-30_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1706300266 Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2017 17:00:21 -0000 This is a multi-part message in MIME format. --------------616DF0D5FFD8046B94A0BE41 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 06/30/2017 11:53 AM, Eric Rescorla wrote: > > On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk > wrote: > > > > The pull request also has some text: > > +If the expected arrival time is in the window, then the server > +checks to see if it has recorded a matching ClientHello. It > +either aborts the handshake with an "illegal_parameter" alert > +or accepts the PSK but reject 0-RTT. If no matching ClientHello > +is found, then it accepts 0-RTT and then stores the ClientHello for > +as long as the expected_arrival_time is inside the window. > +Servers MAY also implement data stores with false positives, such as > +Bloom filters, in which case they MUST respond to apparent replay by > +rejecting 0-RTT but MUST NOT abort the handshake. > > I am not sure why we are giving servers a choice between aborting > and accepting the PSK but rejecting 0-RTT (if a matching > ClientHello is found), especially not without giving guidance as > to why they might choose one or the other. My natural inclination > would be to have the expected behavior be to abort and only fall > back to the other behavior if using a scheme with false positives, > but Ekr thinks Erik Nygren was in support of just continuing on > with 1-RTT. It looks like this was > https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 > > , where I ... took the opposite position from what I just said my > "natural inclination" was, amusingly enough. But still, why does > this need to be a choice? Rejecting 0-RTT and continuing on to > 1-RTT seems like it would be reasonable in all the cases mentioned > so far. > > > Well, my reason for not wanting to do that is that it's a clear replay > and so should > be a hard failure. So, I'd be happy to mandate abort the handshake, > but if we can't > agree on that, I'd rather have a choice. > Would you be willing to add some discussion about how aborting might give an information channel to an attacker maliciously replaying packets even though it is clearly an error that should be rejected (eventually)? -Ben --------------616DF0D5FFD8046B94A0BE41 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 06/30/2017 11:53 AM, Eric Rescorla wrote:

On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:


The pull request also has some text:

+If the expected arrival time is in the window, then the server
+checks to see if it has recorded a matching ClientHello. It
+either aborts the handshake with an "illegal_parameter" alert
+or accepts the PSK but reject 0-RTT. If no matching ClientHello
+is found, then it accepts 0-RTT and then stores the ClientHello for
+as long as the expected_arrival_time is inside the window.
+Servers MAY also implement data stores with false positives, such as
+Bloom filters, in which case they MUST respond to apparent replay by
+rejecting 0-RTT but MUST NOT abort the handshake.

I am not sure why we are giving servers a choice between aborting and accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), especially not without giving guidance as to why they might choose one or the other.  My natural inclination would be to have the expected behavior be to abort and only fall back to the other behavior if using a scheme with false positives, but Ekr thinks Erik Nygren was in support of just continuing on with 1-RTT.  It looks like this was https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 , where I ... took the opposite position from what I just said my "natural inclination" was, amusingly enough.  But still, why does this need to be a choice?  Rejecting 0-RTT and continuing on to 1-RTT seems like it would be reasonable in all the cases mentioned so far.

Well, my reason for not wanting to do that is that it's a clear replay and so should
be a hard failure. So, I'd be happy to mandate abort the handshake, but if we can't
agree on that, I'd rather have a choice.


Would you be willing to add some discussion about how aborting might give an information channel to an attacker maliciously replaying packets even though it is clearly an error that should be rejected (eventually)?

-Ben
--------------616DF0D5FFD8046B94A0BE41-- From nobody Fri Jun 30 10:19:16 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA3C13144A for ; Fri, 30 Jun 2017 10:19:09 -0700 (PDT) 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 UE_-kjQw2xwp for ; Fri, 30 Jun 2017 10:19:06 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::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 9C3AA131442 for ; Fri, 30 Jun 2017 10:19:06 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id 22so9277924qtw.2 for ; Fri, 30 Jun 2017 10:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=Ja6TMsJQcuoMA66fm7crF3zxoBJa/CNW/5qTNOF+gRg=; b=eJ4dzDPmkk4POT2FYiLtoesOovdFY3Iu3Eynw4/F2tpfxVUMfSfoggafGi13AICC5s VI1umKT1fLlTHb0emq3vFG+lvaxfFOu1r65dJlnn08eu0v+u1KrmsJ6c/BytIc18yqbR MY0E+BUGx/DDsGApTyQX4ieWMs5Pl/PuknsHa7EHmbl6z0un/8b/DbyA1hWN7p5Aa7RL Gb0OH2S74f8BZuVvd00WZSM5Z8sn5+HRO3T9gmsuZA/9UWa+nsDaueFsjozvwtk8J0ye a9sHdXIS9jilKuxVOBtFTIIMf9gpknr8zgA7TmIUd02nJbj4wobkHrCjZJB4wW1iUy6F d2PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=Ja6TMsJQcuoMA66fm7crF3zxoBJa/CNW/5qTNOF+gRg=; b=qDT6817NOmXOS/A/ZgSxDyCIc8nvheHNbYF7NDbyvi2K2DmIteDSBeGKfvPSqZwaf+ oMj4lcPvuLOJRDfojU5F2jcnM6wDXe1Zv+1IoSxdszw3OP9jzZu1bCneR2beauFsdG3o ViyPOfc9CEas8JuInyMn17YF3rC8ODskUIo3bgJiDwdSqtDNLqBbYiuHkuL4gKR2clav I143IVfRtQMcP2yuZM58U23aUgH+Rve/yRIQL8qFRck0qGOvOjkOdMf5kUrPwofS3d3J CSZGN1ihBXCIWHgi2dS/X0HA4kyf+yBErwj2yHFQHl7tWbnJGVlniGUBnP2D83gpx0I0 5r9A== X-Gm-Message-State: AKS2vOx6bnbcw4iKIWEvv68dKhmg49kg1wkTB7PN2sj9Fa3eKytcu627 DIwzONPT9xQpnyseKbCvw0eTXAMg9Q== X-Received: by 10.237.36.11 with SMTP id r11mr29128395qtc.159.1498843145740; Fri, 30 Jun 2017 10:19:05 -0700 (PDT) MIME-Version: 1.0 Sender: nygren@gmail.com Received: by 10.12.169.25 with HTTP; Fri, 30 Jun 2017 10:19:05 -0700 (PDT) In-Reply-To: References: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> From: Erik Nygren Date: Fri, 30 Jun 2017 13:19:05 -0400 X-Google-Sender-Auth: T05T9dr1pHu27V4ij0NHv4Xr_gs Message-ID: To: Eric Rescorla Cc: Benjamin Kaduk , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a11408b0446a8830553309dea" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2017 17:19:09 -0000 --001a11408b0446a8830553309dea Content-Type: text/plain; charset="UTF-8" On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla wrote: > > On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk wrote: > >> On 06/29/2017 03:53 PM, Eric Rescorla wrote: >> >> I have updated the PR to match people's comments. I would like to merge >> this soon, so please get any final comments in. >> >> >> I made a couple comments on the PR that are more appropriate for the >> list, so I'll repeat them here and hopefully get replies from the broader >> audience. >> >> >> First off, I think we should MUST-level require servers to implement a >> hard limit on the number of replays accepted. However, it doesn't quite >> seem realistic to require "MUST use either [single-use tickets] or >> [ClientHello recording]". My preference would be "MUST use either >> [single-use tickets], [ClientHello recording], or equivalently strong >> protection", but I don't know what level of support we have for such a >> strong requirement. As an alternative, I will also put out "MUST limit >> replays to at most the number of endpoints capable of accepting connections >> for a given identity, and SHOULD provide even stronger replay protections, >> such as [single-use tickets] or [ClientHello recording]." I think we have >> general agreement that strong anti-replay as described in the document is >> feasible for a single-server deployment, and this last formulation is >> achievable in multi-server environments by just giving each server its own >> local per-server protection. (My main reason for wanting a MUST-level hard >> cap is that I worry that millions/billions of replays will have really >> nasty consequences in terms of DoS and side channel issues.) >> >> But, this has been quite a long thread spread out over multiple >> forums/email subjects, so I've also probably forgotten some of the >> arguments presented against having MUST-level strong anti-replay >> requirements; I'd greatly appreciate if someone could repeat them here for >> everyone's consideration. >> >> >> The pull request also has some text: >> >> +If the expected arrival time is in the window, then the server >> +checks to see if it has recorded a matching ClientHello. It >> +either aborts the handshake with an "illegal_parameter" alert >> +or accepts the PSK but reject 0-RTT. If no matching ClientHello >> +is found, then it accepts 0-RTT and then stores the ClientHello for >> +as long as the expected_arrival_time is inside the window. >> +Servers MAY also implement data stores with false positives, such as >> +Bloom filters, in which case they MUST respond to apparent replay by >> +rejecting 0-RTT but MUST NOT abort the handshake. >> >> I am not sure why we are giving servers a choice between aborting and >> accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), >> especially not without giving guidance as to why they might choose one or >> the other. My natural inclination would be to have the expected behavior >> be to abort and only fall back to the other behavior if using a scheme with >> false positives, but Ekr thinks Erik Nygren was in support of just >> continuing on with 1-RTT. It looks like this was >> https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 , >> where I ... took the opposite position from what I just said my "natural >> inclination" was, amusingly enough. But still, why does this need to be a >> choice? Rejecting 0-RTT and continuing on to 1-RTT seems like it would be >> reasonable in all the cases mentioned so far. >> > > Well, my reason for not wanting to do that is that it's a clear replay and > so should > be a hard failure. So, I'd be happy to mandate abort the handshake, but if > we can't > agree on that, I'd rather have a choice. > Are there scenarios where the duplication might be accidental rather than a malicious attack? For example, one might see cases where combining 0RTT with TFO and network packet duplication could result in two initial 0RTT flights. One could also see "TCP accelerator" middleboxes doing similar things where the first flight gets replayed. In both of these cases, only one will actually successfully establish a TLS connection and move forwards, but if the successful one is the one that is aborted then the connection will fail. If 0RTT is rejected and both are allowed to proceed, then the bogus accidental replay will be dropped and the legit connection will succeed. Erik --001a11408b0446a8830553309dea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On F= ri, Jun 30, 2017 at 12:53 PM, Eric Rescorla <ekr@rtfm.com> wrot= e:

On Fri, Jun 30, 2017 = at 9:32 AM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
=20 =20 =20
On 06/29/2017 03:53 PM, Eric Rescorla wrote:
=20
I have updated the PR to match people's comments= . I would like to merge this soon, so please get any final comments in.

 I made a couple comments on the PR that are more appropriate for the list, so I'll repeat them here and hopefully get replies from the broader audience.


First off, I think we should MUST-level require servers to implement a hard limit on the number of replays accepted.=C2=A0 However, it doesn= 't quite seem realistic to require "MUST use either [single-use tickets] or [ClientHello recording]".=C2=A0 My preference would be= "MUST use either [single-use tickets], [ClientHello recording], or equivalently strong protection", but I don't know what level o= f support we have for such a strong requirement.=C2=A0 As an alternative,= I will also put out "MUST limit replays to at most the number of endpoints capable of accepting connections for a given identity, and SHOULD provide even stronger replay protections, such as [single-use tickets] or [ClientHello recording]."=C2=A0 I think we have genera= l agreement that strong anti-replay as described in the document is feasible for a single-server deployment, and this last formulation is achievable in multi-server environments by just giving each server its own local per-server protection.=C2=A0 (My main reason for wanting a MUST-level hard cap is that I worry that millions/billions of replays will have really nasty consequences in terms of DoS and side channel issues.)

But, this has been quite a long thread spread out over multiple forums/email subjects, so I've also probably forgotten some of the arguments presented against having MUST-level strong anti-replay requirements; I'd greatly appreciate if someone could repeat them here for everyone's consideration.


The pull request also has some text:

+If the expected arrival time is in the window, then the server
+checks to see if it has recorded a matching ClientHello. It
+either aborts the handshake with an "illegal_parameter" aler= t
+or accepts the PSK but reject 0-RTT. If no matching ClientHello
+is found, then it accepts 0-RTT and then stores the ClientHello for +as long as the expected_arrival_time is inside the window.
+Servers MAY also implement data stores with false positives, such as
+Bloom filters, in which case they MUST respond to apparent replay by
+rejecting 0-RTT but MUST NOT abort the handshake.

I am not sure why we are giving servers a choice between aborting and accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), especially not without giving guidance as to why they might choose one or the other.=C2=A0 My natural inclination would be to have the expected behavior be to abort and only fall back to the other behavior if using a scheme with false positives, but Ekr thinks Erik Nygren was in support of just continuing on with 1-RTT.=C2= =A0 It looks like this was https://github.com/tlswg/tls13-spec/pull/1005= #discussion_r114924733 , where I ... took the opposite position from what I just said my "natural inclination" was, amusingly enough.=C2=A0 But still,= why does this need to be a choice?=C2=A0 Rejecting 0-RTT and continuing on to 1-RTT seems like it would be reasonable in all the cases mentioned so far.

Well, my reaso= n for not wanting to do that is that it's a clear replay and so should<= /div>
be a hard failure. So, I'd be happy to mandate abort the hand= shake, but if we can't
agree on that, I'd rather have a c= hoice.

Are there sc= enarios where the duplication might be accidental rather than a malicious a= ttack?
For example, one might see cases where combining 0RTT = with TFO and network packet
duplication could result in two i= nitial 0RTT flights.=C2=A0 One could also see "TCP accelerator"
middleboxes doing similar things where the first flight gets r= eplayed.

In both of these cases, only one will actually s= uccessfully establish a TLS connection
and move forwards, but= if the successful one is the one that is aborted then
the c= onnection will fail.=C2=A0 If 0RTT is rejected and both are allowed to proc= eed,
then the bogus accidental replay will be dropped and the= legit connection will succeed.

=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 Erik




--001a11408b0446a8830553309dea-- From nobody Fri Jun 30 10:24:03 2017 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A599131454 for ; Fri, 30 Jun 2017 10:24:02 -0700 (PDT) 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 ftTQvDNv2MH8 for ; Fri, 30 Jun 2017 10:23:59 -0700 (PDT) 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 67FD8131448 for ; Fri, 30 Jun 2017 10:23:59 -0700 (PDT) Received: by mail-yw0-x231.google.com with SMTP id a12so3676312ywh.3 for ; Fri, 30 Jun 2017 10:23:59 -0700 (PDT) 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=7IqWWB390clHfGdCXJweUd36+nlqNAZ4PiMZEQEevIw=; b=OZ6hvrXqxRIpBF2DKvdAqy7RXzgmXO19JL+ZmYla/ADmjKABATaQKIQIr11mOG3ZVY LBRCHIh34tLEMF9dbEklIWPnYKyJF+z+hCt5zQDlvEBAk53ID/ZRUUnq6ftjSdCzuSdg 9WywuexUCKUgnwt2RKHWjcZrdVAxdVdX6j7TGydkUQFzCGpjfzkPfccU3e+IE1D7PB1v mtST0KIMQTeWolOcU1y/FfyiRM+rZM+JRcGSKyV34C9HqMYswiUcXRe2HD5JbFH2ix1x 9SBGbnfpZGo9RB4eTIIZZKET/MTuCsaguqyP+UY7ErPOL6SkOHmW9g4g+fklCMhTOMzV 9dzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=7IqWWB390clHfGdCXJweUd36+nlqNAZ4PiMZEQEevIw=; b=sUleb8DWo3RxiZ8YRHnWUMW5AjZsGCwoEZLWi5wByNzBib2X3hpmrXP/6iJrcn9s2o gK6C5GWRG+umtIdhZTMZ0/g44CMmhJqanLAEnrm4kcNE0JxGjTaYpgf3ZyuXfIvO7l/s QdJRseS9AeLe8a6w/ArtvEVs/NBE0gpgzlJ5x1aFD6zQvgKbpPa8EDBbsZiBQ4e+3hvS 4GQTBXGeByBcYDUMYX66DcaqoKMwQidcZTs4ayxHXFcvzKptj/TmiFSToOC3lKSusFnY +L6zoKW14DlhuxI6JgzaSiGSvJUAgM8X2l1fBkwbOsWPuOb0MbL/LAOy6Df8Yoq/0naW +ePA== X-Gm-Message-State: AKS2vOwz3p2p5dwFYsCZcM+CrFPtlcIk93o951gvLj8R3gN4R1mXUdHN VUVAHGMQArkZKjEO+9LMqtoUkKT36sa8NBs= X-Received: by 10.129.109.206 with SMTP id i197mr10596021ywc.24.1498843438653; Fri, 30 Jun 2017 10:23:58 -0700 (PDT) MIME-Version: 1.0 Received: by 10.13.215.9 with HTTP; Fri, 30 Jun 2017 10:23:18 -0700 (PDT) In-Reply-To: References: <7b5b28f1-60d5-0979-f789-0471df33dba9@akamai.com> From: Eric Rescorla Date: Fri, 30 Jun 2017 10:23:18 -0700 Message-ID: To: Erik Nygren Cc: Benjamin Kaduk , "tls@ietf.org" Content-Type: multipart/alternative; boundary="001a114dd266bc56ad055330ae29" Archived-At: Subject: Re: [TLS] Closing on 0-RTT X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "This is the mailing list 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, 30 Jun 2017 17:24:02 -0000 --001a114dd266bc56ad055330ae29 Content-Type: text/plain; charset="UTF-8" On Fri, Jun 30, 2017 at 10:19 AM, Erik Nygren wrote: > On Fri, Jun 30, 2017 at 12:53 PM, Eric Rescorla wrote: > >> >> On Fri, Jun 30, 2017 at 9:32 AM, Benjamin Kaduk >> wrote: >> >>> On 06/29/2017 03:53 PM, Eric Rescorla wrote: >>> >>> I have updated the PR to match people's comments. I would like to merge >>> this soon, so please get any final comments in. >>> >>> >>> I made a couple comments on the PR that are more appropriate for the >>> list, so I'll repeat them here and hopefully get replies from the broader >>> audience. >>> >>> >>> First off, I think we should MUST-level require servers to implement a >>> hard limit on the number of replays accepted. However, it doesn't quite >>> seem realistic to require "MUST use either [single-use tickets] or >>> [ClientHello recording]". My preference would be "MUST use either >>> [single-use tickets], [ClientHello recording], or equivalently strong >>> protection", but I don't know what level of support we have for such a >>> strong requirement. As an alternative, I will also put out "MUST limit >>> replays to at most the number of endpoints capable of accepting connections >>> for a given identity, and SHOULD provide even stronger replay protections, >>> such as [single-use tickets] or [ClientHello recording]." I think we have >>> general agreement that strong anti-replay as described in the document is >>> feasible for a single-server deployment, and this last formulation is >>> achievable in multi-server environments by just giving each server its own >>> local per-server protection. (My main reason for wanting a MUST-level hard >>> cap is that I worry that millions/billions of replays will have really >>> nasty consequences in terms of DoS and side channel issues.) >>> >>> But, this has been quite a long thread spread out over multiple >>> forums/email subjects, so I've also probably forgotten some of the >>> arguments presented against having MUST-level strong anti-replay >>> requirements; I'd greatly appreciate if someone could repeat them here for >>> everyone's consideration. >>> >>> >>> The pull request also has some text: >>> >>> +If the expected arrival time is in the window, then the server >>> +checks to see if it has recorded a matching ClientHello. It >>> +either aborts the handshake with an "illegal_parameter" alert >>> +or accepts the PSK but reject 0-RTT. If no matching ClientHello >>> +is found, then it accepts 0-RTT and then stores the ClientHello for >>> +as long as the expected_arrival_time is inside the window. >>> +Servers MAY also implement data stores with false positives, such as >>> +Bloom filters, in which case they MUST respond to apparent replay by >>> +rejecting 0-RTT but MUST NOT abort the handshake. >>> >>> I am not sure why we are giving servers a choice between aborting and >>> accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), >>> especially not without giving guidance as to why they might choose one or >>> the other. My natural inclination would be to have the expected behavior >>> be to abort and only fall back to the other behavior if using a scheme with >>> false positives, but Ekr thinks Erik Nygren was in support of just >>> continuing on with 1-RTT. It looks like this was >>> https://github.com/tlswg/tls13-spec/pull/1005#discussion_r114924733 , >>> where I ... took the opposite position from what I just said my "natural >>> inclination" was, amusingly enough. But still, why does this need to be a >>> choice? Rejecting 0-RTT and continuing on to 1-RTT seems like it would be >>> reasonable in all the cases mentioned so far. >>> >> >> Well, my reason for not wanting to do that is that it's a clear replay >> and so should >> be a hard failure. So, I'd be happy to mandate abort the handshake, but >> if we can't >> agree on that, I'd rather have a choice. >> > > Are there scenarios where the duplication might be accidental rather than > a malicious attack? > For example, one might see cases where combining 0RTT with TFO and network > packet > duplication could result in two initial 0RTT flights. One could also see > "TCP accelerator" > middleboxes doing similar things where the first flight gets replayed. > Sure, and this is a good reason to hard fail because it helps us find stuff like that. In both of these cases, only one will actually successfully establish a TLS > connection > and move forwards, but if the successful one is the one that is aborted > then > the connection will fail. > Sure, though of course clients can also retry. -Ekr > If 0RTT is rejected and both are allowed to proceed, > then the bogus accidental replay will be dropped and the legit connection > will succeed. > > Erik > > > > > --001a114dd266bc56ad055330ae29 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Jun 30, 2017 at 10:19 AM, Erik Nygren <nygren@akamai.com&g= t; wrote:
On Fri, Jun= 30, 2017 at 12:53 PM, Eric Rescorla <ekr@rtfm.com> wrote:
On Fri, Jun 30, 2017 at 9:32 AM, Benjamin= Kaduk <bkaduk@akamai.com> wrote:
=20 =20 =20
On 06/29/2017 03:53 PM, Eric Rescorla wrote:
=20
I have updated the PR to match people's comments= . I would like to merge this soon, so please get any final comments in.

 I made a couple comments on the PR that are more appropriate for the list, so I'll repeat them here and hopefully get replies from the broader audience.


First off, I think we should MUST-level require servers to implement a hard limit on the number of replays accepted.=C2=A0 However, it doesn= 't quite seem realistic to require "MUST use either [single-use tickets] or [ClientHello recording]".=C2=A0 My preference would be= "MUST use either [single-use tickets], [ClientHello recording], or equivalently strong protection", but I don't know what level o= f support we have for such a strong requirement.=C2=A0 As an alternative,= I will also put out "MUST limit replays to at most the number of endpoints capable of accepting connections for a given identity, and SHOULD provide even stronger replay protections, such as [single-use tickets] or [ClientHello recording]."=C2=A0 I think we have genera= l agreement that strong anti-replay as described in the document is feasible for a single-server deployment, and this last formulation is achievable in multi-server environments by just giving each server its own local per-server protection.=C2=A0 (My main reason for wanting a MUST-level hard cap is that I worry that millions/billions of replays will have really nasty consequences in terms of DoS and side channel issues.)

But, this has been quite a long thread spread out over multiple forums/email subjects, so I've also probably forgotten some of the arguments presented against having MUST-level strong anti-replay requirements; I'd greatly appreciate if someone could repeat them here for everyone's consideration.


The pull request also has some text:

+If the expected arrival time is in the window, then the server
+checks to see if it has recorded a matching ClientHello. It
+either aborts the handshake with an "illegal_parameter" aler= t
+or accepts the PSK but reject 0-RTT. If no matching ClientHello
+is found, then it accepts 0-RTT and then stores the ClientHello for +as long as the expected_arrival_time is inside the window.
+Servers MAY also implement data stores with false positives, such as
+Bloom filters, in which case they MUST respond to apparent replay by
+rejecting 0-RTT but MUST NOT abort the handshake.

I am not sure why we are giving servers a choice between aborting and accepting the PSK but rejecting 0-RTT (if a matching ClientHello is found), especially not without giving guidance as to why they might choose one or the other.=C2=A0 My natural inclination would be to have the expected behavior be to abort and only fall back to the other behavior if using a scheme with false positives, but Ekr thinks Erik Nygren was in support of just continuing on with 1-RTT.=C2= =A0 It looks like this was https://github.com/tlswg/tls= 13-spec/pull/1005#discussion_r114924733 , where I ... took the opposite position from what I just said my "natural inclination" was, amusingly enough.=C2=A0 But still,= why does this need to be a choice?=C2=A0 Rejecting 0-RTT and continuing on to 1-RTT seems like it would be reasonable in all the cases mentioned so far.

Well, my reaso= n for not wanting to do that is that it's a clear replay and so should<= /div>
be a hard failure. So, I'd be happy to mandate abort the hand= shake, but if we can't
agree on that, I'd rather have a c= hoice.

Are t= here scenarios where the duplication might be accidental rather than a mali= cious attack?
For example, one might see cases where combining 0RTT with TFO a= nd network packet
duplication could result in two initial 0RT= T flights.=C2=A0 One could also see "TCP accelerator"
middleboxes doing similar things where the first flight gets replayed.

Sure, and this i= s a good reason to hard fail because it helps us find stuff like that.


In both of t= hese cases, only one will actually successfully establish a TLS connection<= br>
and move forwards, but if the successful one is the one that = is aborted then
the connection will fail.
<= /div>

Sure, though of course clients can al= so retry.

-Ekr


=
=C2=A0
=C2=A0 If 0RTT is rejected= and both are allowed to proceed,
then the bogus accidental r= eplay will be dropped and the legit connection will succeed.

=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 Erik





--001a114dd266bc56ad055330ae29-- From nobody Fri Jun 30 18:13:43 2017 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 971F8131451; Fri, 30 Jun 2017 18:13:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tls@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.55.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <149887161558.430.6454612018892579370@ietfa.amsl.com> Date: Fri, 30 Jun 2017 18:13:35 -0700 Archived-At: Subject: [TLS] I-D Action: draft-ietf-tls-tls13-vectors-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.22 List-Id: "This is the mailing list 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, 01 Jul 2017 01:13:36 -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 : Example Handshake Traces for TLS 1.3 Author : Martin Thomson Filename : draft-ietf-tls-tls13-vectors-01.txt Pages : 36 Date : 2017-06-30 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. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-tls13-vectors/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tls-tls13-vectors-01 https://datatracker.ietf.org/doc/html/draft-ietf-tls-tls13-vectors-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-tls13-vectors-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/