Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[Nikos Mavrogiannopoulos]

On Mon, 2015-11-02 at 23:54 -0800, Colm MacCárthaigh wrote:

> * I think the statement "can be implemented easily without being
> vulnerable to software side-channel attacks" is too strong, unless
> one wants to really litigate what "software side-channels are".
> Unless I'm mistaken, as a stream cipher ChaCha20 is *more* vulnerable
> to a class of size-based  side-channels than a block cipher would be.
> A simple form of attack would be to monitor connections to wikipedia
> and identify which pages a user is browsing; from observing just the
> size of requests and responses [*] it's pretty easy for an attacker
> to (offline) create a graph of HTML page sizes and the sizes of the
> images they load and then (in real time) to correlate things such
> that they can uniquely identify the page loaded. This attack is
> feasible with both stream and block ciphers, but it is far easier
> with a stream cipher. Similarly, the compressed map tiles attack that
> shows where an online maps user is browsing is much more effective
> with a stream cipher. [http://blog.ioactive.com/2012/02/ssl-traffic
> -analysis-on-google-maps.html]

I agree that protecting the length of the communicated data is
important, but there is nothing specific to this cipher. All modern TLS
ciphers today are stream ciphers (i.e., AES-GCM and AES-CCM (*)), so
they offer the same protection as chacha20 with respect to hiding the
length. Maybe we should add a note about that in the security
considerations.

regards,
Nikos

(*). More specifically their mode is a stream cipher mode

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

Re: [TLS] Revised I-D: Use of KCipher-2 with Poly1305 in Transport Layer Security (draft-kiyomoto-kcipher2-tls-02)

[Hanno Böck]

On Mon, 2 Nov 2015 22:52:59 +0900
Yoshiaki Hori  wrote:

> Name:   draft-kiyomoto-kcipher2-tls
> Revision:   02
> Title:  Use of KCipher-2 with Poly1305 in Transport Layer

I feel I've written almost the same on multiple occassions lately, but
I'll do it again:

I think one of the major problems of TLS (and other crypto) in the past
has been that it has grown to be too complicated. I'm therefore
strictly against adding new options without any reasonable rationale
behind them.

The rationale here seems to be "let's have another algorithm just in
case". That "just in case" here is that if chacha20 turns out to be
insecure we don't have another streamcipher. However we'd of course
still have AES-GCM.

I think TLS has suffered a lot in the past from feature bloat. I'd
propose to go the other way: Lower the number of options if they don't
make sense.

Therefore: Please don't introduce another algorithm into TLS - unless
you have very good arguments (i.e. it is vastly better than the other
options or you have serious arguments why you think AES-GCM and
chacha20/poly1305 are in danger of being real-world-broken any time
soon).

-- 
Hanno Böck
http://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: BBB51E42


pgpyXsPnjb0bl.pgp
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] AES-OCB patent situation resolved

[Aaron Zauner]

Hi,

As some might remember I've been working on a draft for AES-OCB
cipher-suites in TLS
(https://datatracker.ietf.org/doc/draft-zauner-tls-aes-ocb/). Where,
ideally, OCB would replace CCM [or even GCM, but I don't think that's
realistic] in TLS.

Beginning of this summer Rogaway and IBM (Jutla) filed IPR exemptions
for this very draft for use of OCB specific to TLS. What was unclear
until very recently was if patents by Gligor/Donescu would be relevant
to this document. I've been told that these patents aren't relevant
because IPR by Rogaway and Jutla pre-dates them by years.

In more detail:
```
IBM patents/publications on IAPM/OCB

7,093,126 "Encryption schemes with almost free integrity awareness "
filed April 14, 2000.
(Fig 10 describes the parallelized scheme. Also described in detail in
text of the patent).

Eprint ia.cr/2000/039 "Encryption Modes with Almost Free Message
Integrity". 1 Aug 2000.
(Section 2.1 describes the parallelizable mode IAPM, also see Fig 2 on
page 5).

6,963,976  "Symmetric key authenticated encryption schemes " filed
November 3, 2000.
(Claim 23 says all blocks to be encrypted in parallel).

Gligor and Donescu Patents/Publications

6,973,187 "Block encryption method and schemes for data confidentiality
and integrity protection " filed Jan 18, 2001.

This patent does not describe ciphertext stealing as done in Rogaway's
OCB to handle non-standard size messages.
Also, it does not describe any ways to generate the whitening sequence
as used in OCB (which are not already covered by IBM patents).

Virgil D. Gligor, Pompiliu Donescu:
Fast Encryption and Authentication: XCBC Encryption and XECB
Authentication Modes. FSE 2001: 92-108

Their earlier paper from 1999 was a broken scheme. (Virgil D. Gligor,
Pompiliu Donescu:
Integrity-Aware PCBC Encryption Schemes. Security Protocols Workshop
1999: 153-171)
```

Usual reminder here: I'm not a lawyer and neither intimately familiar
with US patent law in particular.

Hope this gets the discussion started again, as OCB is a very elegant
mode which I'd like to see deployed instead of CCM, at least. What's
missing currently are implementations. There're primitives available in
OpenSSL but code is missing for OCB use with TLS. I probably won't find
time to add this code, so if someone is interested, please let me know.

Aaron



signature.asc
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[Benjamin Kaduk]

On 11/02/2015 04:06 PM, internet-dra...@ietf.org wrote:
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-tls-chacha20-poly1305-01
>
>

Section 2,

%   1.  The 64-bit record sequence number is serialized as an 8-byte,
%   big-endian value and padded on the left with 4 zeroes.

I assume you mean zero octets/bytes, and not ASCII '0' (or EBCDIC, or ...)

"padded on the left" also has some potential for ambiguity (though not as 
much); something about "four zero octets are prepended to the stream" might be 
less ambiguous.

-Ben

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

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[Colm MacCárthaigh]

On Tue, Nov 3, 2015 at 2:34 AM, Nikos Mavrogiannopoulos 
wrote:
>
> I agree that protecting the length of the communicated data is
> important, but there is nothing specific to this cipher.


I wouldn't contest that; I just think the I-D is over-selling ChaCha20's
side-channel resistance. I would argue that in real practical terms it is
less side-channel resistant than AES-CBC; but I think a reader would be
left with the opposite impression.

Still huge +1 on adding it; it's exciting to get a fast modern
well-designed cipher into TLS.

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

Re: [TLS] I-D Action: draft-ietf-tls-chacha20-poly1305-01.txt

[Brian Smith]

Brian Smith  wrote:

> This way, one Poly1305 invocation per record could be saved, potentially, 
> forapplication_data records, which is the common case.
>
>
This is still true, but...


> An implementation that avavoids sending encrypted alerts and avoids 
> renegotiation could avoid writing code for the case where non-empty AAD is 
> needed, and could share the exact same code between TLS 1.2 and TLS 1.3 for 
> ChaCha20-Poly1305.
>
>
This isn't true, because of the Finished message. So, it is not quite as
good of an idea as I thought, but still it seems like it could be
worthwhile.

Cheers,
Brian
-- 
https://briansmith.org/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Queue for TLS Remote Attendees

[Alexa Morris]

If you are planning to participate in the TLS session here at IETF 94 today — 
either locally in Yokohama or as a remote participant — we want to make sure 
that you are aware that the IETF is providing a remote participants with a 
fairly new way to ask questions or make comments. In addition to using the 
Jabber room, for the TLS session there is also the opportunity for remote 
participants to enter a virtual queue and ask questions directly into the 
meeting room. 

This experimental queue was used in several sessions at IETF 92 and IETF 93, so 
you may have already seen it in action. There will be two queues for the TLS 
session — a virtual queue and an actual (in-room) queue. Remote attendees will 
log into the Meetecho platform and will have a virtual mic line that they can 
enter if they have a question or comment. In-room participants will continue to 
use normal mic lines. 

Instructions for remote participants are at 
http://ietf94.conf.meetecho.com/index.php/Remote_Participation. 

Information on how to join the Meetecho session is at 
http://ietf94.conf.meetecho.com/.

Verify that you are WebRTC compliant (required to use the virtual queue) by 
performing a self-test here: 
http://ietf94.conf.meetecho.com/index.php/Self_Test. 

Regards,
Alexa

--
Alexa Morris / Executive Director / IETF
48377 Fremont Blvd., Suite 117, Fremont, CA  94538
Phone: +1.510.492.4089 / Fax: +1.510.492.4001
Email: amor...@amsl.com

Managed by Association Management Solutions (AMS)
Forum Management, Meeting and Event Planning
www.amsl.com 

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

[TLS] Deprecating tls-unique for TLS 1.3

[Alexey Melnikov]

Just to clarify, I think it is fine to define TLS 1.3 replacement for 
tls-unique using Exporters. But I suggest for interoperability this should be 
defined as a new channel binding with a new name, as opposed to just redefining 
tls-unique.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Deprecating tls-unique for TLS 1.3

[Eric Rescorla]

Can you expand on this a bit? Perhaps propose some text.

-Ekr


On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov 
wrote:

> Just to clarify, I think it is fine to define TLS 1.3 replacement for
> tls-unique using Exporters. But I suggest for interoperability this should
> be defined as a new channel binding with a new name, as opposed to just
> redefining tls-unique.
> ___
> 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

Re: [TLS] Deprecating tls-unique for TLS 1.3

[Yoav Nir]

Can’t we just say that all previous uses of tis-unique will instead get an 
exporter generated with the label “tis-unique” ?

> On 4 Nov 2015, at 11:12 AM, Alexey Melnikov  wrote:
> 
> Just to clarify, I think it is fine to define TLS 1.3 replacement for 
> tls-unique using Exporters. But I suggest for interoperability this should be 
> defined as a new channel binding with a new name, as opposed to just 
> redefining tls-unique.
> ___
> 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] I-D Action: draft-ietf-tls-rfc4492bis-05.txt

[internet-drafts]

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Transport Layer Security Working Group of the 
IETF.

Title   : Elliptic Curve Cryptography (ECC) Cipher Suites for 
Transport Layer Security (TLS) Versions 1.2 and Earlier
Authors : Yoav Nir
  Simon Josefsson
  Manuel Pegourie-Gonnard
Filename: draft-ietf-tls-rfc4492bis-05.txt
Pages   : 31
Date: 2015-11-03

Abstract:
   This document describes key exchange algorithms based on Elliptic
   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
   protocol.  In particular, it specifies the use of Ephemeral Elliptic
   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
   use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
   Digital Signature Algorithm (EdDSA) as new authentication mechanisms.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-05


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/

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

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-05.txt

[Yoav Nir]

This includes three of the pull requests we discussed at the meeting.

I’ve left the change in IANA registry policies out for now because we’re not 
yet in agreement about how that should go.

Yoav

> On 4 Nov 2015, at 12:05 PM, internet-dra...@ietf.org wrote:
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security Working Group of 
> the IETF.
> 
>Title   : Elliptic Curve Cryptography (ECC) Cipher Suites for 
> Transport Layer Security (TLS) Versions 1.2 and Earlier
>Authors : Yoav Nir
>  Simon Josefsson
>  Manuel Pegourie-Gonnard
>   Filename: draft-ietf-tls-rfc4492bis-05.txt
>   Pages   : 31
>   Date: 2015-11-03
> 
> Abstract:
>   This document describes key exchange algorithms based on Elliptic
>   Curve Cryptography (ECC) for the Transport Layer Security (TLS)
>   protocol.  In particular, it specifies the use of Ephemeral Elliptic
>   Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
>   use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
>   Digital Signature Algorithm (EdDSA) as new authentication mechanisms.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc4492bis/
> 
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-tls-rfc4492bis-05
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc4492bis-05
> 
> 
> 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/
> 
> ___
> 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

Re: [TLS] Deprecating tls-unique for TLS 1.3

[Martin Thomson]

On 4 November 2015 at 11:16, Yoav Nir  wrote:
> Can’t we just say that all previous uses of tis-unique will instead get an 
> exporter generated with the label “tis-unique” ?


That was my thought here: redefine what it means to generate tls-unique.

That's part of why I asked about the size.  We should ensure that
clients are not made sad if they receive a tls-unique that is longer
than 96 bits.

We could backport this to 1.2, but I'm not sure whether this is a new
feature or whether it's a bug fix.  If it is the former, I'm not that
enthusiastic about a backport.

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

Re: [TLS] Deprecating tls-unique for TLS 1.3

[Alexey Melnikov]

On 04/11/2015 11:13, Eric Rescorla wrote:
> Can you expand on this a bit? Perhaps propose some text.

So, tls-unique is defined in RFC 5929 as:

   Description: The first TLS Finished message sent (note: the Finished
   struct, not the TLS record layer message containing it) in the most
   recent TLS handshake of the TLS connection being bound to (note: TLS
   connection, not session, so that the channel binding is specific to
   each connection regardless of whether session resumption is used).
   If TLS renegotiation takes place before the channel binding
   operation, then the first TLS Finished message sent of the latest/
   inner-most TLS connection is used.  Note that for full TLS
   handshakes, the first Finished message is sent by the client, while
   for abbreviated TLS handshakes (session resumption), the first
   Finished message is sent by the server.

This is currently independent of the version of TLS used. This is also
broken for TLS 1.2 due to the triple handshake vulnerability.

I don't think we can just redefine this for TLS 1.3 and expect this to
work, because APIs for getting this information out of TLS libraries are
going to be different if Exporters are used.
Also, if "tls-unique" is redefined, an old implementation of
"tls-unique" would be unable to talk to a new implementation. For
example if one end is IMAP client using SCRAM or GS2 against IMAP server
implementing the same.

I think there is desire to fix this for both TLS 1.2 and 1.3. I think
the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03
(Channel Bindings for TLS based on the PRF) and update it for TLS 1.3. I
think conceptually what Simon did is very similar to what was proposed
in the TLS meeting today.


> -Ekr
> 
> 
> On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov
> mailto:alexey.melni...@isode.com>> wrote:
> 
> Just to clarify, I think it is fine to define TLS 1.3 replacement
> for tls-unique using Exporters. But I suggest for interoperability
> this should be defined as a new channel binding with a new name, as
> opposed to just redefining tls-unique.

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

Re: [TLS] Deprecating tls-unique for TLS 1.3

[Martin Thomson]

What is wrong with getTlsUnique2() or getBetterTlsUnique() ?  It's not
a drop-in replacement, but it indicates that the app understands the
change.  Otherwise, we might have to signal this in TLS 1.2 proper.
1.3 can just be fixed.

On 4 November 2015 at 15:42, Alexey Melnikov  wrote:
> On 04/11/2015 11:13, Eric Rescorla wrote:
>> Can you expand on this a bit? Perhaps propose some text.
>
> So, tls-unique is defined in RFC 5929 as:
>
>Description: The first TLS Finished message sent (note: the Finished
>struct, not the TLS record layer message containing it) in the most
>recent TLS handshake of the TLS connection being bound to (note: TLS
>connection, not session, so that the channel binding is specific to
>each connection regardless of whether session resumption is used).
>If TLS renegotiation takes place before the channel binding
>operation, then the first TLS Finished message sent of the latest/
>inner-most TLS connection is used.  Note that for full TLS
>handshakes, the first Finished message is sent by the client, while
>for abbreviated TLS handshakes (session resumption), the first
>Finished message is sent by the server.
>
> This is currently independent of the version of TLS used. This is also
> broken for TLS 1.2 due to the triple handshake vulnerability.
>
> I don't think we can just redefine this for TLS 1.3 and expect this to
> work, because APIs for getting this information out of TLS libraries are
> going to be different if Exporters are used.
> Also, if "tls-unique" is redefined, an old implementation of
> "tls-unique" would be unable to talk to a new implementation. For
> example if one end is IMAP client using SCRAM or GS2 against IMAP server
> implementing the same.
>
> I think there is desire to fix this for both TLS 1.2 and 1.3. I think
> the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03
> (Channel Bindings for TLS based on the PRF) and update it for TLS 1.3. I
> think conceptually what Simon did is very similar to what was proposed
> in the TLS meeting today.
>
>
>> -Ekr
>>
>>
>> On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov
>> mailto:alexey.melni...@isode.com>> wrote:
>>
>> Just to clarify, I think it is fine to define TLS 1.3 replacement
>> for tls-unique using Exporters. But I suggest for interoperability
>> this should be defined as a new channel binding with a new name, as
>> opposed to just redefining tls-unique.
>
> ___
> 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

Re: [TLS] Deprecating tls-unique for TLS 1.3

[Alexey Melnikov]

On 04/11/2015 15:48, Martin Thomson wrote:
> What is wrong with getTlsUnique2() or getBetterTlsUnique() ?

That would be fine, but see below.

> It's not a drop-in replacement,

If it is not a drop in replacement, it should have a different name.
Channel bindings are referenced by names in various protocols (and some
implementations can support more than one channel binding type), in
particular in SASL SCRAM and SASL GS2.

> but it indicates that the app understands the
> change.  Otherwise, we might have to signal this in TLS 1.2 proper.
> 1.3 can just be fixed.

My point are:

1) "tls-unique" is defined in TLS version-independent way, so it is
currently defined for TLS 1.3 (as long as TLS 1.3 still uses Finished
messages).

2) It would be much better to implement a single recommended TLS channel
binding that works for both TLS 1.2 and TLS 1.3

3) We can't redefine how tls-unique works for TLS 1.2 without breaking
existing implementations (I can explain this in more details, if needed).

All of these made me think that defining a new channel binding that
works for both TLS 1.2 and TLS 1.3 would be a better option.

> On 4 November 2015 at 15:42, Alexey Melnikov  
> wrote:
>> On 04/11/2015 11:13, Eric Rescorla wrote:
>>> Can you expand on this a bit? Perhaps propose some text.
>>
>> So, tls-unique is defined in RFC 5929 as:
>>
>>Description: The first TLS Finished message sent (note: the Finished
>>struct, not the TLS record layer message containing it) in the most
>>recent TLS handshake of the TLS connection being bound to (note: TLS
>>connection, not session, so that the channel binding is specific to
>>each connection regardless of whether session resumption is used).
>>If TLS renegotiation takes place before the channel binding
>>operation, then the first TLS Finished message sent of the latest/
>>inner-most TLS connection is used.  Note that for full TLS
>>handshakes, the first Finished message is sent by the client, while
>>for abbreviated TLS handshakes (session resumption), the first
>>Finished message is sent by the server.
>>
>> This is currently independent of the version of TLS used. This is also
>> broken for TLS 1.2 due to the triple handshake vulnerability.
>>
>> I don't think we can just redefine this for TLS 1.3 and expect this to
>> work, because APIs for getting this information out of TLS libraries are
>> going to be different if Exporters are used.
>> Also, if "tls-unique" is redefined, an old implementation of
>> "tls-unique" would be unable to talk to a new implementation. For
>> example if one end is IMAP client using SCRAM or GS2 against IMAP server
>> implementing the same.
>>
>> I think there is desire to fix this for both TLS 1.2 and 1.3. I think
>> the best way would be to take Simon's draft-josefsson-sasl-tls-cb-03
>> (Channel Bindings for TLS based on the PRF) and update it for TLS 1.3. I
>> think conceptually what Simon did is very similar to what was proposed
>> in the TLS meeting today.
>>
>>
>>> -Ekr
>>>
>>>
>>> On Wed, Nov 4, 2015 at 11:12 AM, Alexey Melnikov
>>> mailto:alexey.melni...@isode.com>> wrote:
>>>
>>> Just to clarify, I think it is fine to define TLS 1.3 replacement
>>> for tls-unique using Exporters. But I suggest for interoperability
>>> this should be defined as a new channel binding with a new name, as
>>> opposed to just redefining tls-unique.
>>
>> ___
>> 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

Re: [TLS] Deprecating tls-unique for TLS 1.3

[Karthikeyan Bhargavan]

Despite the proposed extended master secret fix in RFC7627, I now think that 
tls-unique needs
to be deprecated for all versions of TLS, and that we should design and 
recommend
a new channel binding that can be used uniformly by SASL/TokenBinding/FIDO etc.

I have read Simon’s draft and it is a plausible approach 
https://tools.ietf.org/html/draft-josefsson-sasl-tls-cb-03 

The TokenBinding folks have gone with an exporters-based binding, which makes 
sense too.
Both of them rely on the session hash construction and should be compatible 
with TLS 1.3.
One question to ask is whether the binding should be per-session (i.e. per 
master secret) or per-connection.

Best,
Karthik

> 
> On Wed, Nov 4, 2015 at 7:00 AM, Martin Thomson  > wrote:
> On 4 November 2015 at 11:16, Yoav Nir  > wrote:
> > Can’t we just say that all previous uses of tis-unique will instead get an 
> > exporter generated with the label “tis-unique” ?
> 
> 
> That was my thought here: redefine what it means to generate tls-unique.
> 
> That's part of why I asked about the size.  We should ensure that
> clients are not made sad if they receive a tls-unique that is longer
> than 96 bits.
> 
> We could backport this to 1.2, but I'm not sure whether this is a new
> feature or whether it's a bug fix.  If it is the former, I'm not that
> enthusiastic about a backport.
> 
> ___
> 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