Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABDBD12B095 for ; Wed, 7 Sep 2016 16:19:41 -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 OaVXDl0M_zCV for ; Wed, 7 Sep 2016 16:19:38 -0700 (PDT) Received: from mail-yw0-x22e.google.com (mail-yw0-x22e.google.com [IPv6:2607:f8b0:4002:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92D2912B010 for ; Wed, 7 Sep 2016 16:19:38 -0700 (PDT) Received: by mail-yw0-x22e.google.com with SMTP id g192so18721170ywh.1 for ; Wed, 07 Sep 2016 16:19:38 -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=W6BVOblMjS7tSHc7ywlV959+byiHbJkwIJ0hp5+zwMQ=; b=rbNhmUL8qkc/O30DIxlagJacIFNee3Yqhv0B/HqRQtT4y0fXAOU72ft38JBbIC3wVE nlC5WqmN9szH1xwRxQmNF1GB5OGGpAmPgRbl7KJunSK43ggTzekMUuxL6W+SHVgwCQe6 ZTm3bQBRR57q2cI7Zl6SsFZ+xvc7+lNFBugh5GpzxZFGGyJ4efibwEtrZfWY8wWVwKHV 7ITgjFwxN8o7LGMOysHJoz7wUAVeLCj0VmcoQl94q0Um0u298fp8qCo0lC75O7180Xy3 qIBC+1SqbZr8KOd/Ry8TgZwJZASodngoXw4FpE65EwhpQvvtb+5SeoAFfN3/g75Cc/Go KxrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=W6BVOblMjS7tSHc7ywlV959+byiHbJkwIJ0hp5+zwMQ=; b=HTBq0ahgdYH1wHc6Htvgiaw4BYqO+S4VfhtJPHizmrxtrMRdLNDK8hisyPRPV9/En9 pqUSXwWhUx5GVvYP3R/Yx6D+cb0YOQAH0NAXyHkg1PieYPuxIqtTyvinn8rM5fFq6K+l ss07peIa0Ns3YaiXYEz0UqR9Fd+xAaVzncDIf0hEDK+N63+Y9tB+vFagyLSJHccE1Poa 4Xn4cgE2doOMFvH43AR+5fDhK0BG6bcB+eODKY/lGmqt274veoA2f7Pcr3dlwrK8MO46 bItK3QTEQ3UzLbn0k5juSRwAKPi041elG15cAz1erfJ2a3kqvfoMbGpn4x6BMgQN80ty WBYw== X-Gm-Message-State: AE9vXwOq+qoNfjncvz2fPgGzPxrQxzuwwazhdOaqEtz1NJc5pu9UsA0ymCfg82FADn4TnpiK/bLbASAwuwhgEQ== X-Received: by 10.13.220.1 with SMTP id f1mr41940256ywe.289.1473290377654; Wed, 07 Sep 2016 16:19:37 -0700 (PDT) MIME-Version: 1.0 Received: by 10.129.32.70 with HTTP; Wed, 7 Sep 2016 16:18:56 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 7 Sep 2016 16:18:56 -0700 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=94eb2c0809f09ca236053bf3255f Archived-At: Cc: Antoine Delignat-Lavaud , "tls@ietf.org" Subject: Re: [TLS] Finished stuffing X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "This is the mailing list 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 Sep 2016 23:19:42 -0000 --94eb2c0809f09ca236053bf3255f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk wrote: > I don't understand the proposal. > Are you proposing to eliminate resumption_context (RC) from All its > current uses and replace it with the hello_finished extension? > Yes. > Or is this to affect only certain uses of RC? Which ones? > One important property of RC is that it serves as a binding with the > original context that generated a resumption PSK, in particular a binding > with the server's identity (certificate). This is not achieved by the > hello_finished extension, is it? > It is supposed to do so. The reasoning is: - RMS is unchanged and therefore derived from the server certificate - The HelloFinished computation is HKDF(F(RMS), ) and therefore also is derived from the server certificate. Is that insufficient. I also have a problem with names. "Resumption context" is very explicit > about providing, well, resumption context. > "Hello_Finished", in turn, means nothing. > Also, RC may better match the notion of "binder" hence more naturally > requiring collision resistance, while all Finished uses in TLS (1.3 and > before) have a MAC functionality (for which, say, 128 bits are good enoug= h) > and it would be better not to abuse them for other uses. > Two points about this: 1. The Finished in TLS 1.3 is always Hash.length, and our minimum hash is SHA-256, so I believe we have enough strength here. We could of course require a minimum size. 2. I wouldn't object to changing names here, of course. Best, -Ekr > Anyways, maybe this is just the result of my misunderstanding of the > proposal. > > Hugo > > > On Wed, Sep 7, 2016 at 11:26 AM, Eric Rescorla wrote: > >> >> >> On Wed, Sep 7, 2016 at 8:25 AM, David Benjamin >> wrote: >> >>> On Wed, Sep 7, 2016 at 11:11 AM Eric Rescorla wrote: >>> >>>> On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lavaud < >>>> antoine@delignat-lavaud.fr> wrote: >>>> >>>>> Regarding whether the placeholder zeros should be part of the >>>>> transcript for the stuffed finished, an argument against it is that i= t >>>>> violates the incremental nature of the session hash. If the hash stop= s >>>>> before the placeholder, it can be resumed with the computed finished; >>>>> otherwise, it must be rolled back. >>>>> >>>> >>>> This isn't a big deal for me (or I think any other implementor) either >>>> way, because of the actual way we compute the hash. >>>> >>> >>> To expand on that, because the final PRF hash is not known at the time >>> we send ClientHello, most implementations I've seen just buffer the ful= l >>> transcript before this point. >>> >>> But one could also keep a rolling hash of all the supported PRFs >>> (there's all of two of them if you lose TLS 1.1 and below), so I think >>> that's a good argument for using the prefix rather than zeros. For >>> implementations keeping a buffer, I don't think it matters, so let's ke= ep >>> both strategies happy. >>> >> >> This is certainly fine with me. >> >> -Ekr >> >> >>> >>> David >>> >>> >>> >>>> -Ekr >>>> >>>> >>>>> >>>>> Best, >>>>> >>>>> Antoine >>>>> >>>>> >>>>> Le 2016-09-07 05:49, Joseph Salowey a =C3=A9crit : >>>>> >>>>>> Hi Folks, >>>>>> >>>>>> The chairs want to make sure this gets some proper review. Please >>>>>> respond with comments by Friday so we can make some progress on this >>>>>> issue. >>>>>> >>>>>> Thanks, >>>>>> >>>>>> J&S >>>>>> >>>>>> On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin >>>>>> wrote: >>>>>> >>>>>> I think this is a good idea. It's kind of weird, but it avoids >>>>>>> giving the early Finished such a strange relationship with the >>>>>>> handshake transcript. Also a fan of doing away with multiple PSK >>>>>>> identities if we don't need it. >>>>>>> >>>>>>> As a bonus, this removes the need to route a "phase" parameter into >>>>>>> the traffic key calculation since we'll never derive more than one >>>>>>> epoch off of the same traffic secret. Combine that with the >>>>>>> two-ladder KeyUpdate and we no longer need any concatenation or >>>>>>> other label-munging at all. Simply use labels "key" and "iv" and th= e >>>>>>> record-layer just exposes a single UseTrafficSecret function which >>>>>>> saves the traffic secret (for KeyUpdate), derives the traffic keys, >>>>>>> and engages the new AEAD in one swoop without mucking about with >>>>>>> phases, traffic directions, whether we are client or server, etc. >>>>>>> >>>>>>> David >>>>>>> >>>>>>> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla wrote: >>>>>>> >>>>>>> I should also mention that this makes the implementation a fair bit >>>>>>> simpler because: >>>>>>> >>>>>>> 1. You can make all the decisions on the server side immediately >>>>>>> upon receiving the ClientHello >>>>>>> without waiting for Finished. >>>>>>> 2. You don't need to derive early handshake traffic keys. >>>>>>> >>>>>>> >From an implementor's perspective, this outweighs the messing arou= nd >>>>>>> with the ClientHello buffer. >>>>>>> -Ekr >>>>>>> >>>>>>> On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla wrote: >>>>>>> >>>>>>> Folks, >>>>>>> >>>>>>> I have just posted a WIP PR for what I'm calling "Finished Stuffing= " >>>>>>> >>>>>>> https://github.com/tlswg/tls13-spec/pull/615 [1] >>>>>>> >>>>>>> >>>>>>> I would welcome comments on this direction and whether I am missing >>>>>>> anything important. >>>>>>> >>>>>>> OVERVIEW >>>>>>> This PR follows on a bunch of discussions we've had about the >>>>>>> redundancy >>>>>>> of Finished and resumption_ctx. This PR makes the following changes= : >>>>>>> >>>>>>> - Replace the 0-RTT Finished with an extension you send in the >>>>>>> ClientHello *whenever* you do PSK. >>>>>>> - Get rid of resumption context (because it is now replaced by >>>>>>> the ClientHello.hello_finished. >>>>>>> >>>>>>> RATIONALE >>>>>>> The reasoning for this change is: >>>>>>> >>>>>>> - With ordinary PSK you don't get any assurance that the other side >>>>>>> knows the PSK. >>>>>>> >>>>>>> - With 0-RTT you get some (subject to the usual anti-replay >>>>>>> guarantees) via the Finished message. >>>>>>> >>>>>>> - If we were to include the 0-RTT Finished message in the handshake >>>>>>> transcript, then we wouldn't need the resumption context because >>>>>>> the transcript would transitively include the PSK via the >>>>>>> Finished. >>>>>>> >>>>>>> So the natural thing to do would be to always send 0-RTT Finished >>>>>>> but unfortunately: >>>>>>> >>>>>>> 1. You can't just send the 0-RTT Finished whenever you do PSK >>>>>>> because >>>>>>> that causes potential compat problems with mixed 1.3/1.2 networks >>>>>>> (the same ones we have with 0-RTT, but at least that's opt-in). >>>>>>> >>>>>>> 2. You also can't send the 0-RTT Finished with PSK because you can >>>>>>> currently offer multiple PSK identities. >>>>>>> >>>>>>> The on-list discussion has suggested we could relax condition #2 an= d >>>>>>> only have one identity. And we can fix condition #1 by stuffing the >>>>>>> Finished in an extension (with some hacks to make this easier). Thi= s >>>>>>> PR enacts that. >>>>>>> >>>>>>> FAQS >>>>>>> - What gets included in the handshake transcript? >>>>>>> The whole ClientHello including the computed hello_finished >>>>>>> extension. >>>>>>> >>>>>>> - Isn't this a hassle to implement? >>>>>>> It turns out not to be. The basic reason is that at the point >>>>>>> where >>>>>>> the client sends the ClientHello and the server processes, it >>>>>>> doesn't >>>>>>> yet know which Hash will be chosen for HKDF and so NSS (and I >>>>>>> believe >>>>>>> other stacks) buffers the ClientHello in plaintext, so hashing >>>>>>> only >>>>>>> part of it is easy. I've done it in NSS and this part is quite >>>>>>> easy. >>>>>>> >>>>>>> POTENTIAL VARIATIONS/TODOs >>>>>>> There are a number of possible variations we might want to look at: >>>>>>> >>>>>>> 1. Moving obfuscated_ticket_age to its own extension (out of >>>>>>> early_data_indication). This provides additional anti-replay >>>>>>> for the CH at the 0.5RTT sending point. I believe we should >>>>>>> make this change. >>>>>>> >>>>>>> 2. Tweaking the data to be hashed to just hash the ClientHello >>>>>>> prefix without the 0-filled verify_data. This is not >>>>>>> significantly >>>>>>> harder or easier to implement and basically depends on whether >>>>>>> you prefer the invariant of "always hash complete messages" or >>>>>>> "always hash valid pieces of transcript". See above for notes >>>>>>> on buffering. >>>>>>> >>>>>>> 3. Allow multiple PSKs. Technically you could make this design >>>>>>> work with >1 PSK but stuffing multiple verify_data values in >>>>>>> the ClientHello. E.g,, >>>>>>> >>>>>>> opaque FinishedValue<0..255>; >>>>>>> >>>>>>> struct { >>>>>>> FinishedValue finisheds<0..2^16-1>; >>>>>>> } HelloFinished; >>>>>>> >>>>>>> Based on the list discussion, it seems like nobody wants >1 PSK, >>>>>>> so I think one is simpler; I just wanted to note that these >>>>>>> changes weren't totally coupled. >>>>>>> >>>>>>> 4. External context values. Several people have pointed out that it >>>>>>> might be convenient to have an external context value hashed >>>>>>> into the transcript. One way to do this would be to include >>>>>>> it under the Finished. That's not difficult if people want to, >>>>>>> with the default being empty. >>>>>>> >>>>>>> 5. Hugo brought up on the list that we need to make very clear that >>>>>>> the "hello_finished" is being used to bind the handshakes and >>>>>>> that it depends on collision resistance. I have not forgotten >>>>>>> this >>>>>>> and text on that point would be appreciated. >>>>>>> >>>>>>> Comments welcome. >>>>>>> -Ekr >>>>>>> >>>>>>> _______________________________________________ >>>>>>> TLS mailing list >>>>>>> TLS@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tls [2] >>>>>>> >>>>>> >>>>>> _______________________________________________ >>>>>> TLS mailing list >>>>>> TLS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/tls [2] >>>>>> >>>>>> >>>>>> >>>>>> Links: >>>>>> ------ >>>>>> [1] https://github.com/tlswg/tls13-spec/pull/615 >>>>>> [2] https://www.ietf.org/mailman/listinfo/tls >>>>>> >>>>>> _______________________________________________ >>>>>> 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 >>>>> >>>> _______________________________________________ >>>> 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 >> >> > --94eb2c0809f09ca236053bf3255f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 7, 2016 at 4:02 PM, Hugo Krawczyk <hugo@ee.technion.a= c.il> wrote:
I don'= t =C2=A0understand the proposal.=C2=A0
Are you proposing to eliminate resumption_co= ntext (RC) from All its current uses and replace it with the hello_finished= extension?

Yes.

=
=C2=A0
Or is this to af= fect only certain uses of RC? Which ones?
One important property of RC is that it serves as= a binding with the original context that generated a resumption PSK, in pa= rticular a binding with the server's identity (certificate). This is no= t achieved by the hello_finished extension, is it?

It is supposed to do so. The reasoning is:

- RMS is unchanged and therefore derived from the server c= ertificate
- The HelloFinished computation is HKDF(F(RMS), <Cl= ientHello>) and therefore also is derived from the server certificate.

Is that insufficient.


=
I also have a problem with names. = "Resumption context" is very explicit about providing, well, resu= mption context.=C2=A0
"Hello_Finished", in turn, means nothing.
=
Also, RC may = better match the notion of "binder" hence more naturally requirin= g collision resistance, while all Finished uses in TLS (1.3 and before) hav= e a MAC functionality (for which, say, 128 bits are good enough) and it wou= ld be better not to abuse them for other uses.

Two points about this:

1. The Fini= shed in TLS 1.3 is always Hash.length, and our minimum hash is SHA-256, so = I believe we have enough strength here. We could of course require a minimu= m size.
2. I wouldn't object to changing names here, of cours= e.

Best,
-Ekr


Anyways, maybe this is just the result of my = misunderstanding of the proposal.
=
Hug= o


On Wed, Sep 7, 2016 at 11:2= 6 AM, Eric Rescorla <ekr@rtfm.com> wrote:


On Wed, Sep 7, 2016 at 8:25 AM, David Benjamin <davidben@chromium.org> wrote:
On W= ed, Sep 7, 2016 at 11:11 AM Eric Rescorla <ekr@rtfm.com> wrote:
On Wed, Sep 7, 2016 at 6:54 AM, Antoine Delignat-Lav= aud <antoine@delignat-lavaud.fr> wrote:
=
Regarding whether the placeholder zeros should be part of the transcript fo= r the stuffed finished, an argument against it is that it violates the incr= emental nature of the session hash. If the hash stops before the placeholde= r, it can be resumed with the computed finished; otherwise, it must be roll= ed back.

=
This isn't a= big deal for me (or I think any other implementor) either way, because of = the actual way we compute the hash.

To expand on that, because the final PRF hash is no= t known at the time we send ClientHello, most implementations I've seen= just buffer the full transcript before this point.

But one could also keep a rolling hash of all the supported PRFs (there&#= 39;s all of two of them if you lose TLS 1.1 and below), so I think that'= ;s a good argument for using the prefix rather than zeros. For implementati= ons keeping a buffer, I don't think it matters, so let's keep both = strategies happy.

= This is certainly fine with me.

-Ekr
=C2=A0

David<= /div>

=C2=A0
-Ekr



Best,

Antoine


Le 2016-09-07 05:49, Joseph Salowey a =C3=A9crit=C2=A0:
Hi Folks,

The chairs want to make sure this gets some proper review.=C2=A0 =C2=A0Plea= se
respond with comments by Friday so we can make some progress on this
issue.

Thanks,

J&S

On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin
<davidben@chr= omium.org> wrote:

I think this is a good idea. It's kind of weird, but it avoids
giving the early Finished such a strange relationship with the
handshake transcript. Also a fan of doing away with multiple PSK
identities if we don't need it.

As a bonus, this removes the need to route a "phase" parameter in= to
the traffic key calculation since we'll never derive more than one
epoch off of the same traffic secret. Combine that with the
two-ladder KeyUpdate and we no longer need any concatenation or
other label-munging at all. Simply use labels "key" and "iv&= quot; and the
record-layer just exposes a single UseTrafficSecret function which
saves the traffic secret (for KeyUpdate), derives the traffic keys,
and engages the new AEAD in one swoop without mucking about with
phases, traffic directions, whether we are client or server, etc.

David

On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla <ekr@rtfm.com> wrote:

I should also mention that this makes the implementation a fair bit
simpler because:

1. You can make all the decisions on the server side immediately
upon receiving the ClientHello
without waiting for Finished.
2. You don't need to derive early handshake traffic keys.

>From an implementor's perspective, this outweighs the messing aroun= d
with the ClientHello buffer.
-Ekr

On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:

Folks,

I have just posted a WIP PR for what I'm calling "Finished Stuffin= g"

https://github.com/tlswg/tls13-spec/pul= l/615 [1]


I would welcome comments on this direction and whether I am missing
anything important.

OVERVIEW
This PR follows on a bunch of discussions we've had about the
redundancy
of Finished and resumption_ctx. This PR makes the following changes:

- Replace the 0-RTT Finished with an extension you send in the
ClientHello *whenever* you do PSK.
- Get rid of resumption context (because it is now replaced by
the ClientHello.hello_finished.

RATIONALE
The reasoning for this change is:

- With ordinary PSK you don't get any assurance that the other side
knows the PSK.

- With 0-RTT you get some (subject to the usual anti-replay
guarantees) via the Finished message.

- If we were to include the 0-RTT Finished message in the handshake
transcript, then we wouldn't need the resumption context because
the transcript would transitively include the PSK via the
Finished.

So the natural thing to do would be to always send 0-RTT Finished
but unfortunately:

1. You can't just send the 0-RTT Finished whenever you do PSK
because
that causes potential compat problems with mixed 1.3/1.2 networks
(the same ones we have with 0-RTT, but at least that's opt-in).

2. You also can't send the 0-RTT Finished with PSK because you can
currently offer multiple PSK identities.

The on-list discussion has suggested we could relax condition #2 and
only have one identity. And we can fix condition #1 by stuffing the
Finished in an extension (with some hacks to make this easier). This
PR enacts that.

FAQS
- What gets included in the handshake transcript?
The whole ClientHello including the computed hello_finished
extension.

- Isn't this a hassle to implement?
It turns out not to be. The basic reason is that at the point
where
the client sends the ClientHello and the server processes, it
doesn't
yet know which Hash will be chosen for HKDF and so NSS (and I
believe
other stacks) buffers the ClientHello in plaintext, so hashing
only
part of it is easy. I've done it in NSS and this part is quite
easy.

POTENTIAL VARIATIONS/TODOs
There are a number of possible variations we might want to look at:

1. Moving obfuscated_ticket_age to its own extension (out of
early_data_indication). This provides additional anti-replay
for the CH at the 0.5RTT sending point. I believe we should
make this change.

2. Tweaking the data to be hashed to just hash the ClientHello
prefix without the 0-filled verify_data. This is not
significantly
harder or easier to implement and basically depends on whether
you prefer the invariant of "always hash complete messages" or "always hash valid pieces of transcript". See above for notes
on buffering.

3. Allow multiple PSKs. Technically you could make this design
work with >1 PSK but stuffing multiple verify_data values in
the ClientHello. E.g,,

opaque FinishedValue<0..255>;

struct {
FinishedValue finisheds<0..2^16-1>;
} HelloFinished;

Based on the list discussion, it seems like nobody wants >1 PSK,
so I think one is simpler; I just wanted to note that these
changes weren't totally coupled.

4. External context values. Several people have pointed out that it
might be convenient to have an external context value hashed
into the transcript. One way to do this would be to include
it under the Finished. That's not difficult if people want to,
with the default being empty.

5. Hugo brought up on the list that we need to make very clear that
the "hello_finished" is being used to bind the handshakes and
that it depends on collision resistance. I have not forgotten
this
and text on that point would be appreciated.

Comments welcome.
-Ekr

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls<= /a> [2]

_______________________________________________
=C2=A0TLS mailing list
=C2=A0TLS@ietf.org =C2=A0https://www.ietf.org/mailman/listinfo/tls [2= ]



Links:
------
[1] https://github.com/tlswg/tls13-spec/pull/615
[2] https://www.ietf.org/mailman/listinfo/tls

_______________________________________________
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
_______________________________________________
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



--94eb2c0809f09ca236053bf3255f--