Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5

[Dang, Quynh (Fed)]

Hi Martin,


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


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


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


Quynh.



From: Martin Thomson 
Sent: Sunday, November 13, 2016 6:54 PM
To: Dang, Quynh (Fed)
Cc: e...@rtfm.com; tls@ietf.org; c...@ietf.org
Subject: Re: [Cfrg] Data limit to achieve Indifferentiability for ciphertext 
with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5

These are intentionally very conservative.  Having implemented this, I
find it OK.  The text cites its sources.  Reading those sources
corrects any misapprehension.

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

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

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

On 14 November 2016 at 05:48, Dang, Quynh (Fed)  wrote:
> Hi Eric and all,
>
>
> Regardless of the actual record size, each 128-bit block encryption is
> performed with a unique 128-bit counter which is formed by the 96-bit IV and
> the 32-bit counter_block value called CB in NIST SP 800-38D under a given
> key as long as the number of encrypted records is not more than 2^64.
>
> Assuming a user would like to limit the probability of a collision among
> 128-bit ciphertext-blocks under 1/2^32, the data limit of the ciphertext (
> or plaintext) is 2^(96/2) (= 2^48) 128-bit blocks which is 2^64 bytes.
>
> Reading the 2nd paragraph of section 5.5, a user might feel that he/she
> needs to rekey a lot more quicker than he/she needs. Putting an
> unnecessarily low data limit of 2^24.5 full-size records (2^38.5 bytes) also
> creates an incorrect negative impression (in my opinion) about GCM.
>
> I would like to request the working group to consider to revise the text.
>
> Regards,
> Quynh.
>
>
> ___
> Cfrg mailing list
> c...@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-01.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 of the IETF.

Title   : ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for 
Transport Layer Security (TLS)
Authors : John Mattsson
  Daniel Migault
Filename: draft-ietf-tls-ecdhe-psk-aead-01.txt
Pages   : 7
Date: 2016-11-13

Abstract:
   This document defines several new cipher suites for the Transport
   Layer Security (TLS) protocol.  The cipher suites are all based on
   the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
   (ECDHE_PSK) key exchange together with the Authenticated Encryption
   with Associated Data (AEAD) algorithms AES-GCM and AES-CCM.  PSK
   provides light and efficient authentication, ECDHE provides perfect
   forward secrecy, and AES-GCM and AES-CCM provides encryption and
   integrity protection.


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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-tls-ecdhe-psk-aead-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-ecdhe-psk-aead-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

Re: [TLS] I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

[Daniel Migault]

I removed all these recommendations on 128/256 security. I believe this
address this thread.

I also believe a profile document would be useful and detail these details.
Do you have any opinion about such a document ?

Tank you for the feed backs!

Yours,
Daniel

On Tue, Nov 8, 2016 at 7:24 PM, Martin Thomson 
wrote:

> On 8 November 2016 at 21:08, Daniel Migault 
> wrote:
> > TLS enable curve negotiation but not for code point. This makes
> restrictions
> > on code points hard to implement.  As a result Endpoints MAY treat
> > negotiation of key sizes smaller than the lower limits as a connection
> error
> > of type insufficient_security(71) for TLS 1.2 and TLS 1.3.
>
> I really had a hard time parsing this.  You don't connect this to
> Diffie-Hellman at all, but I think that is what you are talking about.
> But if your point is that this is an ECDHE-specific draft, then you
> don't need to say anything at all.
>
> nit "TLS enables"
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] early IANA code point assignment request for draft-ietf-tls-ecdhe-psk-aead

[Daniel Migault]

done.

Thanks for the review!

Yours

Daniel

On Tue, Nov 8, 2016 at 1:07 AM, Ilari Liusvaara 
wrote:

> On Mon, Nov 07, 2016 at 10:16:13PM -0500, Daniel Migault wrote:
> > Hi,
> >
> > The current draft is only considering TLS1.2. TLS1.3 is only mentioned
> for
> > advocating AEAD.
> >
> > Do you think we should add text that details how to proceed with TLS1.3 ?
> > If so what do you think of the following text ?
>
> That is, I think the dependency on TLS 1.3 should be downgraded to
> informative (unless that has already been done).
>
> >
> > Yours,
> > Daniel
> >
> >The assigned code points are only expected to be used for TLS1.2.
> >TLS1.3 does not follow the same name convention.  Instead TLS1.3
> >cipher suites are designated according to the AEAD suite as well as
> >the hash function used.  The current combination of AEAD algorithms
> >and Hash fucntion are already defined in TLS.1.3 so there is no need
> >to add additional cipher suites for TLS1.3.
>
> Seems reasonable.
>
> >Instead, in order to used the following ECDHE_PSK authentication
> >method.  TLS1.3 uses a combination of the "key_share" and
> >"psk_key_exchange_modes" extentions. "psk_key_exchange_modes"
> >extension sets its mode to psk_dhe_ke.  The "key_share" extention
> >contains a KeyShareEntry structure that carries the ECDHE parameters.
> >
>
> I think 'used the following' -> 'use the' and first period should be
> comma.
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

[Eric Rescorla]

On Mon, Nov 14, 2016 at 8:54 AM, Kaduk, Ben  wrote:

> I have reviewed this document and have a few minor comments.  I also have
> many editorial notes that can be addressed out of band.
>
> In the abstract and introduction, we have text about the properties that
> TLS is expected to provide, like confidentiality, authentication, etc.  Do
> we want to say anything about avoiding side channels that might leak
> information about the data being exchanged?  I know that we are not 100%
> confident at what exactly we currently achieve in this area, but since we
> have mechanisms that attempt to achieve it, maybe it is worth mentioning.
> (In a similar vein, as davidben reminded me recently, an attacker “who has
> complete control of the network”, as is our stated adversary, can do things
> like trickle packets in one by one and try to see, e.g., where the end of
> early data is and query handshake state.  So some things may not be
> avoidable.)
>

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


In section 4.2.5.1 we talk about how for FFDH peers SHOULD validate each
> other’s public key Y by ensuring that 1 < Y < p-1, which is supposed to
> ensure that the peer is well-behaved and isn’t forcing the local system
> into a small subgroup.  Somehow I thought that additional checks were
> needed to avoid being forced into a small subgroup, but I guess that
> depends on what group it’s in, and I didn’t pull up the RFC 7919 reference
> when I was reading this document.
>

These are the recommendations in 7919, I believe


> In section 4.2.7, we note that the server MUST NOT send the
> “psk_key_exchange_modes” extension, with the implication that the client
> must observer the types of handshake messages that are subsequently
> received in order to determine what the server selected.  I think that we
> had talked about this already some time ago, but just wanted to confirm
> that we are okay with increasing the size of the client state machine in
> this manner.
>

It's not subsequent messages. You determine it from the PreSharedKey and
KeyShare extensions.


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

I think I would rather not.


The coverage of record payload protection (around section 5.2) seems to not
> always make careful distinction between TLSPlaintext, TLSCiphertext,
> TLSInnerPlaintext, and the fields therein.  In some sense this is
> editorial, but there were a lot of places that I flagged, so I wanted to
> call it out to the broader audience and get more eyes on it.  I also didn’t
> find a description of where the length of the AEAD authentication tag gets
> included into a length field for the ciphertext.
>

I'm not following this point. The way to think about this is that the
ciphertext is a specific size. That may be encryption + auth tag or not
(it's possible to design an AEAD algorithm that doesn't have a separate
auth tag).

-Ekr

At the end of section 6.1 we have this little note that “it is assumed that
> closing a connection reliably delivers pending data before destroying the
> transport”, which, if I remember correctly previous discussion on this
> list, is not actually true for linux.  It is perhaps problematic to have an
> assumption that we know is not going to be held for a large proportion of
> implementations.
>
> -Ben
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] housekeeping: uplift RFC 5289 to Proposed Standard

[Sean Turner]

This email addresses the "Uplifting” bullet on slide 6 of the chair slides 
(https://www.ietf.org/proceedings/97/slides/slides-97-tls-tls-wg-chair-slides-00.pdf);
 this is entirely procedural (i.e., there’s really no technical ).

The cipher suite registry's new "WG recommended” column's “Y" values are being 
populated with cipher suites that are on standards track.  The notable 
exceptions are the EC-based AES-GCM ciphers defined in RFC 5289, which is an 
informational RFC.  This point is buried in an earlier version of 
draft-ietf-tls-tls13 and now in the soon to be 
draft-ietf-tls-iana-registry-updates (was 
draft-sandj-tls-iana-registry-updates); the complete list of the pet-TLS 1.3 
suites can be found here: 
https://tools.ietf.org/html/draft-sandj-tls-iana-registry-updates-01#section-6.

We can uplift RFC 5289 to PS from Informational with what essentially amounts 
to an IETF LC; we don't need a new draft (there's no errata).  We want to know 
if there are any objections to starting this process please post a message to 
the list by November 21st if you object (and why).

Please note the following:

-  This "action" is similar to what we're doing with 4492bis (it too is being 
moved to standards track) it's just that we can use this other process.

- RFC 7525, which was published through the UTA WG and is a BCP btw, already 
2119-RECOMMENDs the ciphers.

- RFC 7540 (aka HTTP/2) MUSTs one of the RFC 5289 cipher suites.

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

Re: [TLS] [Cfrg] Data limit to achieve Indifferentiability for ciphertext with TLS 1.3 GCM, and the 2nd paragraph of Section 5.5

[Martin Thomson]

These are intentionally very conservative.  Having implemented this, I
find it OK.  The text cites its sources.  Reading those sources
corrects any misapprehension.

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

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

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

On 14 November 2016 at 05:48, Dang, Quynh (Fed)  wrote:
> Hi Eric and all,
>
>
> Regardless of the actual record size, each 128-bit block encryption is
> performed with a unique 128-bit counter which is formed by the 96-bit IV and
> the 32-bit counter_block value called CB in NIST SP 800-38D under a given
> key as long as the number of encrypted records is not more than 2^64.
>
> Assuming a user would like to limit the probability of a collision among
> 128-bit ciphertext-blocks under 1/2^32, the data limit of the ciphertext (
> or plaintext) is 2^(96/2) (= 2^48) 128-bit blocks which is 2^64 bytes.
>
> Reading the 2nd paragraph of section 5.5, a user might feel that he/she
> needs to rekey a lot more quicker than he/she needs. Putting an
> unnecessarily low data limit of 2^24.5 full-size records (2^38.5 bytes) also
> creates an incorrect negative impression (in my opinion) about GCM.
>
> I would like to request the working group to consider to revise the text.
>
> Regards,
> Quynh.
>
>
> ___
> Cfrg mailing list
> c...@irtf.org
> https://www.irtf.org/mailman/listinfo/cfrg
>

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

Re: [TLS] TLS sessions' agenda uploaded

[Sean Turner]

Sorry 1st session is Tuesday not Wednesday:

Since we’ve got two sessions and the second session conflicts with tcpinc, if 
we end up getting through the presentations scheduled for *Tuesday* we’ll pull 
the Friday presentations forward in this order (based on relevance to TLS1.3):

Rebranding (aka PR#612)
Example Handshake Traces for TLS 1.3
DTLS

spt

> On Nov 14, 2016, at 07:39, Sean Turner  wrote:
> 
> I’ve uploaded the agenda and chair slides:
> https://datatracker.ietf.org/meeting/97/agenda.html
> 
> Since we’ve got two sessions and the second session conflicts with tcpinc, if 
> we end up getting through the presentations scheduled for Wednesday we’ll 
> pull the Friday presentations forward in this order (based on relevance to 
> TLS1.3):
> 
> Rebranding (aka PR#612)
> Example Handshake Traces for TLS 1.3
> DTLS
> 
> spt

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

[TLS] TLS sessions' agenda uploaded

[Sean Turner]

I’ve uploaded the agenda and chair slides:
https://datatracker.ietf.org/meeting/97/agenda.html

Since we’ve got two sessions and the second session conflicts with tcpinc, if 
we end up getting through the presentations scheduled for Wednesday we’ll pull 
the Friday presentations forward in this order (based on relevance to TLS1.3):

Rebranding (aka PR#612)
Example Handshake Traces for TLS 1.3
DTLS

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