Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Jul 2016 12:08:00 -0700

Folks,

I've just submitted draft-ietf-tls-tls13-14.txt and it should
show up on the draft repository shortly. In the meantime you
can find the editor's copy in the usual location at:

  http://tlswg.github.io/tls13-spec/

The major changes in this document are:

* A big restructure to make it read better. I moved the Overview
  to the beginning and then put the document in a more logical
  order starting with the handshake and then the record and
  alerts.

* Totally rewrote the section which used to be called "Security
  Analysis" and is now called "Overview of Security Properties".
  This section is still kind of a hard hat area, so PRs welcome.
  In particular, I know I need to beef up the citations for the
  record layer section.

* Removed the 0-RTT EncryptedExtensions and moved ticket_age
  into the ClientHello. This quasi-reverts a change in -13 that
  made implementation of 0-RTT kind of a pain.

As usual, comments welcome.
-Ekr

* Allow cookies to be longer (*)

* Remove the "context" from EarlyDataIndication as it was undefined
  and nobody used it (*)

* Remove 0-RTT EncryptedExtensions and replace the ticket_age extension
  with an obfuscated version. Also necessitates a change to
  NewSessionTicket (*).

* Move the downgrade sentinel to the end of ServerHello.Random
  to accomodate tlsdate (*).

* Define ecdsa_sha1 (*).

* Allow resumption even after fatal alerts. This matches current
  practice.

* Remove non-closure warning alerts. Require treating unknown alerts as
  fatal.

* Make the rules for accepting 0-RTT less restrictive.

* Clarify 0-RTT backward-compatibility rules.

* Clarify how 0-RTT and PSK identities interact.

* Add a section describing the data limits for each cipher.

* Major editorial restructuring.

* Replace the Security Analysis section with a WIP draft.

(*) indicates changes to the wire protocol which may require implementations
    to update.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Jul 2016 07:16:24 +0300

> As usual, comments welcome.

Did a readthrough, here's a bunch of comments (didn't check the
issues list):

-----------------------------------------------------------------------
> ## Zero-RTT Data
>
>
> [[OPEN ISSUE: Should it be possible to combine 0-RTT with the
> server authenticating via a signature
> https://github.com/tlswg/tls13-spec/issues/443]]

One should note that it is not clear what sort of continuity properties
should be provoded:

- Certificate valid for hostname
- The same key as in last time
- The same certificate as in last time

The last choice obviously limits lifetime of derived PSK to
the parent certificate.

Also, extension matching is quite different between those three (and the
last two are rather different from the current rules, tuned for 0-RTT
only being used with PSK.

> ##  Numbers
> 
> Note that in some cases (e.g., DH parameters) it is necessary to represent
> integers as opaque vectors. In such cases, they are represented as unsigned
> integers (i.e., additional leading zero octets are not used even if the most
> significant bit is set).

Well, I think the DH parameters are gone, but DH public keys are still there,
and those AFAIK are padded with zeroes.

> ###  Client Hello
> 
> When this message will be sent:
> 
> > When a client first connects to a server, it is required to send the
> ClientHello as its first message. The client will also send a
> ClientHello when the server has responded to its ClientHello with a
> ServerHello that selects cryptographic parameters that don't match the
> client's "key_share" extension. In that case, the client MUST send the same
> ClientHello (without modification) except:

Should the "ServerHello" be "HelloRetryRequest"?

> - Including a new KeyShareEntry as the lowest priority share
>   (i.e., appended to the list of shares in the "key_share" extension).
> 
> - Removing the EarlyDataIndication {{early-data-indication}} extension
>   if one was present. Early data is not permitted after HelloRetryRequest.

Also, adding cookie extension if that was present in HRR?

BTW, with the early_data context and cross-connection cookies gone, I
have figured out how to delta-compress the first client_hello and its
rejection against to-be-sent second client hello plus connection
parameters server selected into 6 bytes(!) of space (not including
return-reachability check or MAC).

> ###  Server Hello
> 
> cipher_suite
> : The single cipher suite selected by the server from the list in
>   ClientHello.cipher_suites.  For resumed sessions, this field is
>   the value from the state of the session being resumed.
>   [[TODO: interaction with PSK.]]

Isn't this the true ciphersuite used on this connection, "resumption"
or not? Otherwise you can get into all sorts of crazy situations that
WILL be sources of implementation bugs.

The idea that it isn't true ciphersuite brings me bad flashbacks about
TLS 1.2 ticket "maybe resume" craziness (except this would be even
worse).

> extensions
> : A list of extensions.  Note that only extensions offered by the
>   client can appear in the server's list. In TLS 1.3, as opposed to
>   previous versions of TLS, the server's extensions are split between
>   the ServerHello and the EncryptedExtensions {{encrypted-extensions}}
>   message. The ServerHello MUST only include extensions which are
>   required to establish the cryptographic context. Currently the only
>   such extensions are "key_share", "pre_shared_key", and "early_data".
>   Clients MUST check the ServerHello for the presence of any forbidden
>   extensions and if any are found MUST terminate the handshake with a
>   "illegal_parameter" alert. In prior versions of TLS, the extensions
>   field could be omitted entirely if not needed, similar to
>   ClientHello. As of TLS 1.3, all clients and servers will send at
>   least one extension (at least "key_share" or "pre_shared_key").

Hasn't early_data just moved to EncryptedExtensions?

###  Hello Retry Request

> selected_group
> : The mutually supported group the server intends to negotiate and
>   is requesting a retried ClientHello/KeyShare for.
> {:br }

What is written into this field if server selects pure-PSK ciphersuite
and then decides to reject the ClientHello? Or connections that use
pure-PSK just plain can't be rejected for any reason (including IP
address verification in DTLS?)

> [[NOTE: cipher_suite may disappear. https://github.com/tlswg/tls13-spec/issues/528]]

Currently assuming pure-PSK rejections are possible, cipher_suite is
needed to tell if the next group field contains anything sane or
not...

> The
> server SHOULD send only the extensions necessary for the client to
> generate a correct ClientHello pair (currently no such extensions
> exist). As with ServerHello, a
> HelloRetryRequest MUST NOT contain any extensions that were not first
> offered by the client in its ClientHello.

What about cookie? IIRC, it is allowed to be in HRR even without
being in CH...

> Upon receipt of a HelloRetryRequest, the client MUST first verify that
> the selected_group field corresponds to a group which was provided
> in the "supported_groups" extension in the original ClientHello.  It
> MUST then verify that the selected_group field does not correspond
> to a group which was provided in the "key_share" extension in the
> original ClientHello. If either of these checks fails, then the client
> MUST abort the handshake with a fatal "handshake_failure"
> alert. Clients SHOULD also abort with "handshake_failure" in response
> to any second HelloRetryRequest which was sent in the same connection
> (i.e., where the ClientHello was itself in response to a
> HelloRetryRequest).
>
> Otherwise, the client MUST send a ClientHello with an updated KeyShare
> extension to the server. The client MUST append a new KeyShareEntry
> for the group indicated in the selected_group field to the groups
> in its original KeyShare.

Again, rejections with cookie aren't spurious, and the cookie needs to
be added.

##  Hello Extensions

> An extension type MUST NOT appear in the ServerHello or HelloRetryRequest
> unless the same extension type appeared in the corresponding ClientHello.
> If a client receives an extension type in ServerHello or HelloRetryRequest
> that it did not request in the associated ClientHello, it MUST abort the
> handshake with an "unsupported_extension" fatal alert.

Cookie in HRR might not follow that....

> In general, the specification of each extension type needs to describe the
> effect of the extension both during full handshake and session resumption. Most
> current TLS extensions are relevant only when a session is initiated: when an
> older session is resumed, the server does not process these extensions in
> ClientHello, and does not include them in ServerHello. However, some
> extensions may specify different behavior during session resumption.
> [[TODO: update this and the previous paragraph to cover PSK-based resumption.]]

I would say that it is a bad idea for any extension to do anything
special with "resumption" without very good reasons.

In fact, the only non-connection-control extension that is relevant for
PSK I know is server_name.

Now, ALPN (connection-control by definition!) behaves specially with
early_data for darn good reasons (the ALP is locked). 

This is made worse by the fact that what consistutes "resumption" is not
clearly defined (the ALPN rules are related to early_data, not choosing
PSK #0!).

> ###  Signature Algorithms
>
> * In TLS 1.2, the extension contained hash/signature pairs. The pairs are
>   encoded in two octets, so SignatureScheme values have been allocated to
>   align with TLS 1.2's encoding. Some legacy pairs are left unallocated. These
>   algorithms are deprecated as of TLS 1.3. They MUST NOT be offered or
>   negotiated by any implementation. In particular, MD5 {{SLOTH}} and SHA-224
>   MUST NOT be used.
>
> * ecdsa_secp256r1_sha256, etc., align with TLS 1.2's ECDSA hash/signature pairs.
>   However, the old semantics did not constrain the signing curve.

Also, for interoperability, any legal TLS 1.3 meaning of these algorithms must
be extended to apply to TLS 1.2, even for TLS 1.2 ClientHello. Anything else
would be pointless trap.

This impiles that RSA PSS and EdDSA work in TLS 1.2 and also how those work.

Also, even if meaning of the ECDSA codepoints changed, those would not break
that rule, since new definition is strict subset of old.

> ### Negotiated Groups
> 
> As of TLS 1.3, servers are permitted to send the "supported_groups"
> extension to the client.  If the server has a group it prefers to the
> ones in the "key_share" extension but is still willing to accept the
> ClientHello, it SHOULD send "supported_groups" to update the client's
> view of its preferences.  Clients MUST NOT act upon any information
> found in "supported_groups" prior to successful completion of the
> handshake, but MAY use the information learned from a successfully
> completed handshake to change what groups they offer to a server in
> subsequent connections.

Are those supposed to be filtered to be subset of ones client advertised
or not? E.g. if client didn't indicate support for x448, can the server
still send x448?

> ### Key Share
> 
> If this extension is not provided in a ServerHello or ClientHello,
> and the peer is offering (EC)DHE cipher suites, then the endpoint MUST close
> the connection with a fatal "missing_extension" alert.
> (see {{mti-extensions}})

Doesn't seem to consistent with the other descriptions of this and
pre_shared_key (those are just "MUST NOT select covered ciphersuite if
missing"). Of course, in practice, it might be more this (at least
that's how I would implement it)...

> [[TODO: Recommendation about what the client offers.
> Presumably which integer DH groups and which curves.]]

Bit crazy algorithm: If you haven't heard of this server before,
pick smallest you support, if you have, pick the one it selected
the last time.

> ### Pre-Shared Key Extension
> 
> Note that although 0-RTT data is encrypted with the first PSK identity, the
> server MAY fall back to 1-RTT and select a different PSK identity if multiple
> identities are offered.

The temporal ordering in messages is actually selecting different PSK
and then rejecting 0-RTT.

> ### Early Data Indication
> 
> obfuscated_ticket_age
> : The time since the client learned about the server configuration that it is
>   using, in milliseconds.  This value is added modulo 2^32 to with the
>   "ticket_age_add" value that was included with the ticket, see
>   {{NewSessionTicket}}.  This addition prevents passive observers from
>   correlating sessions unless tickets are reused.  Note: because ticket
>   lifetimes are restricted to a week, 32 bits is enough to represent any
>   plausible age, even in milliseconds.
 
And the addition also prevents correlating session with its parent,
even in case of reuse (this was the reason for switching to addition
from XOR).

> A server MUST validate that the ticket_age is within a small
> tolerance of the time since the ticket was issued (see {{replay-time}}).

Good luck with that...

Also, requirement that the server MUST proceed with the handshake and
reject 0-RTT if that validation fails would be good here...

> 0-RTT messages sent in the first flight have the same content types
> as their corresponding messages sent in other flights (handshake,
> application_data, and alert respectively) but are protected under
> different keys. After all the 0-RTT application data messages (if
> any) have been sent, an "end_of_early_data" alert of type
> "warning" is sent to indicate the end of the flight.
> 0-RTT MUST always be followed by an "end_of_early_data" alert.

This does not talk about if end_of_early_data alert is encrypted or
not (obviously encrypted one won't work if server rejected 0-RTT,
unless server trial-decrypts).

> If any of these checks fail, the server MUST NOT respond
> with the extension and must discard all the remaining first
> flight data (thus falling back to 1-RTT). If the client attempts
> a 0-RTT handshake but the server rejects it, it will generally
> not have the 0-RTT record protection keys and must instead
> trial decrypt each record with the 1-RTT handshake keys
> until it finds one that decrypts properly, and then pick up
> the handshake from that point.

Oh, still trial decryption... Got it.

> #### Processing Order
> 
> Clients are permitted to "stream" 0-RTT data until they
> receive the server's Finished, only then sending the "end_of_early_data"
> alert. In order to avoid deadlock, when accepting "early_data",
> servers MUST process the client's Finished and then immediately
> send the ServerHello, rather than waiting for the client's
> "end_of_early_data" alert.

I think there was some proposal to dump the Finished. Would simplify
implementation. In TLS, there is at least one appdata record with its
MAC to be deprotected. That's not true in DTLS. 

However, even in DTLS, any wrong keys almost certainly cause handshake
to immediately blow up as handshake keys won't match up...

> #### Replay Properties {#replay-time}
> 
> There are several potential sources of error that make an exact
> measurement of time difficult.  Variations in client and server clocks
> are likely to be minimal, outside of gross time corrections.  Network
> propagation delays are most likely causes of a mismatch in legitimate
> values for elapsed time.  Both the NewSessionTicket and ClientHello
> messages might be retransmitted and therefore delayed, which might be
> hidden by TCP.

I don't think variations in clocks are minimal...

I wonder what 95% timeskew interval per day is...

(Oh, and have fun with leap seconds!)

> ###  Encrypted Extensions
> 
> The same extension types MUST NOT appear in both the ServerHello and
> EncryptedExtensions.  If the same extension appears in both locations,
> the client MUST rely only on the value in the EncryptedExtensions
> block.  All server-sent extensions other than those explicitly listed
> in {{server-hello}} or designated in the IANA registry MUST only
> appear in EncryptedExtensions. Extensions which are designated to
> appear in ServerHello MUST NOT appear in EncryptedExtensions. Clients
> MUST check EncryptedExtensions for the presence of any forbidden
> extensions and if any are found MUST terminate the handshake with an
> "illegal_parameter" alert.

This seems inconsistent. In implementation, I would write explicit disjoint
whitelists of extensions for both (and non-whitelisted one is a fatal
error). Explicit whitelisting is safe even on client side, since the
extensions are bounded by client-supported ones.

> ###  Certificate Request
> 
>   - The Extended Key Usage extension in a certificate matches the
>   request when all key purpose OIDs present in the request are also
>   found in the Extended Key Usage certificate extension. The special
>   anyExtendedKeyUsage OID MUST NOT be used in the request.

How are multiple OIDs represented? Multiple EKU OID/value pairs?

> #### Server Certificate Selection
> 
> 
> - 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.

I think the certificate should be REQUIRED to match (as in, not be
inconsistent with it) server_name, even if not ACK'd.

> ###  Certificate Verify
> 
> If sent by a server, the signature algorithm MUST be one offered in the
> client's "signature_algorithms" extension unless no valid certificate chain can be
> produced without unsupported algorithms (see {{signature-algorithms}}). Note that
> there is a possibility for inconsistencies here. For instance, the client might
> offer an ECDHE_ECDSA cipher suite but omit any ECDSA and EdDSA values from its
> "signature_algorithms" extension. In order to negotiate correctly, the server
> MUST check any candidate cipher suites against the "signature_algorithms"
> extension before selecting them. This is somewhat inelegant but is a compromise
> designed to minimize changes to the original cipher suite design.

The exception on not having valid value can not work at all. With
certificates, even if the EE cert is signed with unknown algorithm,
there is a small chance things will work. In contrast, there is
absolutely no chance of success if either endpoint tries ot use this
fallback.

> Note: When used with non-certificate-based handshakes (e.g., PSK), the
> client's signature does not cover the server's certificate directly,
> although it does cover the server's Finished message, which
> transitively includes the server's certificate when the PSK derives
> from a certificate-authenticated handshake.  {{PSK-FINISHED}}
> describes a concrete attack on this mode if the Finished is omitted
> from the signature. It is unsafe to use certificate-based client
> authentication when the client might potentially share the same
> PSK/key-id pair with two different endpoints. In order to ensure
> this, implementations MUST NOT mix certificate-based client
> authentication with pure PSK modes (i.e., those where the
> PSK was not derived from a previous non-PSK handshake).

Does this apply to in-handshake or post-handshake auth? I thought
in-handshake auth with PSK is not possible.

If it is intended to be possible, that's certainly going to be
surprising to implementers, and there are probably going to be multiple
implementations that outright choke if one tries to send
CertificateRequest in (DHE-)PSK mode

> ## Record Payload Protection
> 
> length
> : The length (in bytes) of the following TLSCiphertext.fragment, which
>   is the sum of the lengths of the content and the padding, plus one
>   for the inner content type. The length MUST NOT exceed 2^14 + 256.
>   An endpoint that receives a record that exceeds this length MUST
>   generate a fatal "record_overflow" alert.

Later the document seems to imply that the limit for for content+type+
padding is in fact 16385 bytes.

> ## Per-Record Nonce {#nonce}
> 
> Sequence numbers do not wrap.  If a TLS implementation would need to
> wrap a sequence number, it MUST either rekey ({{key-update}}) or
> terminate the connection.

Maybe add requirement that record with sequence number of 2^64-1 MUST
be either fatal alert or KeyUpdate.

> ## Limits on Key Usage
> 
> For AES-GCM, up to 2^24.5 full-size records may be encrypted on a
> given connection while keeping a safety margin of approximately
> 2^-57 for Authenticated Encryption (AE) security. For
> ChaCha20/Poly1305, the record sequence number will wrap before the
> safety limit is reached.

I would expand that 2^24.5 to some rough number ("about 24 million"?).

And also "will wrap" -> "would wrap". Because such wrapping can't
happen (even if endpoint delays KeyUpdate to RSN 2^64-1).

> ## Key Schedule
> 
> If a given secret is not available, then the 0-value consisting of
> a string of Hash.length zeroes is used.  Note that this does not mean skipping
> rounds, so if PSK is not in use Early Secret will still be
> HKDF-Extract(0, 0).

This might cause fun with future key exchange types...

> # IANA Considerations

> | Extension                                | Recommended |  TLS 1.3  |
> |:-----------------------------------------|------------:|----------:|
> | max_fragment_length [RFC6066]            |         Yes | Encrypted |

I think this needs to be in ServerHello on server-side, given how low-
level it is.

> | user_mapping [RFC4681]                   |         Yes | Encrypted |
> | client_authz [RFC5878]                   |          No | Encrypted |
> | server_authz [RFC5878]                   |          No | Encrypted |

These darn things use Supplemental Data messages, would need to define
where the data goes.  And one can't stick it to extension for
user_mapping and client_authz, because those are sent by the client,
not the server.

> | cookie [[this document]]                 |         Yes | Encrypted/HelloRetryRequest |

Isn't that "Client/HelloRetryRequest"? I don't think EncryptedExtensions
can have Cookie...

> -  TLS SignatureScheme Registry: Values with the first byte in the range
>   0-254 (decimal) are assigned via Specification Required {{RFC2434}}.
>   Values with the first byte 255 (decimal) are reserved for Private
>   Use {{RFC2434}}. This registry SHALL have a "Recommended" column.
>   The registry [shall be/ has been] initially populated with the values described in
>   {{signature-algorithms}}. The following values SHALL be marked as
>   "Recommended": ecdsa_secp256r1_sha256, ecdsa_secp384r1_sha384,
>   rsa_pss_sha256, rsa_pss_sha384, rsa_pss_sha512, ed25519.

Should the two registeries shadowed by this closed?

> ## Cipher Suites
> 
> Note: The values listed for ECDHE and ChaCha/Poly are preliminary but
> are being or will be used for interop testing and therefore are likely to be
> assigned.

Isn't the RFC already published, so the codepoints are stable?

> ## Random Number Generation and Seeding
> 
> To estimate the amount of seed material being produced, add the number of bits
> of unpredictable information in each seed byte. For example, keystroke timing
> values taken from a PC compatible 18.2 Hz timer provide 1 or 2 secure bits
> each, even though the total size of the counter value is 16 bits or more.
> Seeding a 128-bit PRNG would thus require approximately 100 such timer values.

This seems really obsolete. The timers have not been 18.2Hz for years, and
applications running on operating systems damn better use OS services for
random numbers, given that anything else is fraught with peril.

> ## Implementation Pitfalls
> 
> -  Have you ensured that all support for SSL, RC4, EXPORT ciphers, and
>   MD5 (via the "signature_algorithm" extension) is completely removed from
>   all possible configurations that support TLS 1.3 or later, and that
>   attempts to use these obsolete capabilities fail correctly?
>   (see {{backward-compatibility}})

Better to just nuke the code entierely for all versions.

"Disabled" code has nasty tendency of coming back to life.

> -  Do you handle TLS extensions in ClientHello correctly, including
>   unknown extensions or omitting the extensions field completely?

The extensions field can't be omitted in TLS 1.3. And I would
consider TLS 1.2 client implementations that send such messages
as quite pathological.

> Cryptographic details:
> 
> -  What countermeasures do you use to prevent timing attacks against
>   RSA signing operations {{TIMING}}?

Also, ECDSA signing operations do have problems with timing attacks.

> - When verifying RSA signatures, do you accept both NULL and missing parameters?
>   Do you verify that the RSA padding
>   doesn't have additional data after the hash value? {{FI06}}

Also, the lengths need to be correct (not verifying this leads to an
attack). Best just to treat first length bytes >0x82 or >0x83 as
malformed. There is no way to send legimate message with first length
byte >0x83 in TLS.

> #  Overview of Security Properties {#security-analysis}
> 
> [[TODO: This section is still a WIP and needs a bunch more work.]]
> 
> A complete security analysis of TLS is outside the scope of this document.
> In this section, we provide an informal description the desired properties
> as well as references to more detailed work in the research literature
> which provides more formal definitions.
> 
> We cover properties of the handshake separately from those of the record layer.

I think properties of the exporter should be covered as well:

- Is it intended to generate secret data (yes)
- Is it intended to generate connection-unique data (yes)
- Are values for different labels/contexts intended to be computationally
  independent (yes)

(The TLS 1.2 exporter without EMS failed the middle requirement,
creating security issues in applications that assumed the data was
connection-unique.

-----------------------------------------------------------------------

-Ilari

---

From: Dave Garrett <[email-masked]>
Date: Tue, 12 Jul 2016 01:52:57 -0400

Just replying to a few points.

> address verification in DTLS?)

The HelloRetryRequest message is not applicable to pure-PSK, which does not use the KeyShare extension at all. PSK has its own separate extension. ((EC)DHE-PSK uses both together)

The purpose of HelloRetryRequest is to allow for clients to not send full keys for every single algorithm they support, yet allow the server to still pick from that entire list if it needs to. PSK has no equivalent system; pre-shared keys are first-flight or bust. If an (EC)DHE-PSK suite is selected, and a valid PSK identity is selected, the server can use HelloRetryRequest to reject a group in favor of another supported by the client, but it can't reject the suite or identity in this manner. The response to no acceptable PSK identity is either to negotiate another suite or to abort with a fatal alert.

See draft 14 section 4.2.5:
https://tools.ietf.org/html/draft-ietf-tls-tls13-14#section-4.2.5

> Isn't the RFC already published, so the codepoints are stable?

xiaoyinl fixed the second one of those notes, but that was merged after the checkpoint for draft 14. I'll fix this one to just note for ECDHE PSK AES.

> "Disabled" code has nasty tendency of coming back to life.

Emphatically agreed, however I worded it this way to be slightly more general. If I said that all that code should be universally gutted, I'd risk more people ignoring it due to the severe status quo bias that is very common. In lieu of modernizing fully and dropping it completely, having these old features disabled via the same compile-time option that enables building of TLS 1.3 would be acceptable, IMO (though, more trouble than it should be worth, and still not ideal at all). Bikeshedding better wordings in this section would not be unwelcome, if you think anything here can be made better.

> consider TLS 1.2 client implementations that send such messages

Implementations should be expected to handle pathological cases gracefully, even if only to recognize and reject. ;)

Dave

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Jul 2016 12:00:18 +0300

On Tue, Jul 12, 2016 at 01:52:57AM -0400, Dave Garrett wrote:
> The HelloRetryRequest message is not applicable to pure-PSK, which 
> does not use the KeyShare extension at all. PSK has its own separate
> extension. ((EC)DHE-PSK uses both together)

Yes, rejection because of group mismatch can't occur. However, I don't
see any requirement not to reject pure-PSK for cookie check (might be
feasible, if the computational and network load is determined "small
enough").

> xiaoyinl fixed the second one of those notes, but that was merged
> after the checkpoint for draft 14. I'll fix this one to just note
> for ECDHE PSK AES.

IIRC, there was merged patch that changed the reference, but not the
text. Just checked, seems to still be there in Editor's Copy.

-Ilari

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 12 Jul 2016 13:04:11 +0000

Hi Eric and all,

In my opinion, we should give better information about data limit for AES_GCM in TLS 1.3 instead of what is current in the draft 14.

In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf,  what is called confidentiality attack is the known plaintext differentiality attack where the attacker has/chooses two plaintexts, send them to the AES-encryption oracle.  The oracle encrypts one of them, then sends the ciphertext to the attacker.  After seeing the ciphertext, the attacker has some success probability of telling which plaintext was encrypted and this success probability is in the column called "Attack Success Probability" in Table 1.  This attack does not break confidentiality.

If the attack above breaks one of security goal(s) of your individual system, then making success probability of that attack at 2^(-32) max is enough. In that case, the Max number of records is around 2^38.

Regards,
Quynh.

Date: Monday, July 11, 2016 at 3:08 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Folks,

* Define ecdsa_sha1 (*).

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 12 Jul 2016 13:17:46 +0000

Hi Eric and all,

Regards,
Quynh.

From: TLS <[email-masked]<mailto:[email-masked]>> on behalf of Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Monday, July 11, 2016 at 3:08 PM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [TLS] New draft: draft-ietf-tls-tls13-14.txt

Folks,

* Define ecdsa_sha1 (*).

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 12 Jul 2016 14:03:57 +0000

Hi Quynh,

This indistinguishability-based security notion is the confidentiality
notion that is by now generally accepted in the crypto community. Meeting
it is sufficient to guarantee security against many other forms of attack
on confidentiality, which is one of the main reasons we use it.

You say that an attack in the sense implied by breaking this notion does
not break confidentiality. Can you explain what you mean by
"confidentiality", in a precise way? I can then try to tell you whether
this notion will imply yours.

Regards

Kenny 

On 12/07/2016 14:04, "TLS on behalf of Dang, Quynh (Fed)"
<[email-masked] on behalf of [email-masked]> wrote:

>Hi Eric and all, 
>
>
>In my opinion, we should give better information about data limit for
>AES_GCM in TLS 1.3 instead of what is current in the draft 14.
>
>
>In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf,  what is
>called confidentiality attack is the known plaintext differentiality
>attack where
> the attacker has/chooses two plaintexts, send them to the AES-encryption
>oracle.  The oracle encrypts one of them, then sends the ciphertext to
>the attacker.  After seeing the ciphertext, the attacker has some success
>probability of telling which plaintext
> was encrypted and this success probability is in the column called
>“Attack Success Probability” in Table 1.  This attack does not break
>confidentiality. 
>
>
>If the attack above breaks one of security goal(s) of your individual
>system, then making success probability of that attack at 2^(-32) max is
>enough. In that case, the Max number of records is around 2^38.
>
>
>
>
>Regards,
>Quynh. 
>
>
>
>
>
>
>To: "[email-masked]" <[email-masked]>

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 12 Jul 2016 15:12:21 +0000

Hi Kenny,

The indistinguishability-based security notion in the paper is a stronger
security notion than the (old) traditional confidentiality notion.

(*) Indistinguishability notion (framework) guarantees no other attacks
can be better than the indistinguishability bound. Intuitively, you can¹t
attack if you can¹t even tell two things are different or not. So, being
able to say two things are different or not is the minimal condition to
lead to any attack.

The traditional confidentiality definition is that knowing only the
ciphertexts, the attacker can¹t know any content of the corresponding
plaintexts with a greater probability than some value and this value
depends on the particular cipher. Of course, the maximum amount of data
must not be more than some limit under a given key which also depends on
the cipher. 

For example, with counter mode AES_128, Let¹s say encrypting 2^70 input
blocks with a single key. With the 2^70 ciphertext blocks alone (each
block is 128 bits), I don¹t think one can find out any content of any of
the plaintexts. The chance for knowing any block of the plaintexts is
1/(2^128) in this case.

I support the strongest indistinguishability notion mentioned in (*)
above, but in my opinion we should provide good description to the users.
That is why I support the limit around 2^38 records.

Regards,
Quynh. 

On 7/12/16, 10:03 AM, "Paterson, Kenny" <[email-masked]> wrote:

>>³Attack Success Probability² in Table 1.  This attack does not break
>>confidentiality. 
>>
>>

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 12 Jul 2016 15:45:30 +0000

Actually, a more correct way of viewing the limit would be 2^52 encrypted data bytes. To come to the 2^38 record limit, they assume that each record is the maximum 2^14 bytes.  Of course, at a 1Gbps rate, it'd take over a year to encrypt that much data...

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Dang, Quynh (Fed)
> Sent: Tuesday, July 12, 2016 11:12 AM
> To: Paterson, Kenny; Dang, Quynh (Fed); Eric Rescorla; [email-masked]
> Subject: Re: [TLS] New draft: draft-ietf-tls-tls13-14.txt
> 
> Hi Kenny,
> 
> (*) Indistinguishability notion (framework) guarantees no other attacks can
> be better than the indistinguishability bound. Intuitively, you can¹t attack if
> you can¹t even tell two things are different or not. So, being able to say two
> things are different or not is the minimal condition to lead to any attack.
> 
> The traditional confidentiality definition is that knowing only the ciphertexts,
> the attacker can¹t know any content of the corresponding plaintexts with a
> greater probability than some value and this value depends on the particular
> cipher. Of course, the maximum amount of data must not be more than
> some limit under a given key which also depends on the cipher.
> 
> blocks with a single key. With the 2^70 ciphertext blocks alone (each block is
> 128 bits), I don¹t think one can find out any content of any of the plaintexts.
> The chance for knowing any block of the plaintexts is
> 1/(2^128) in this case.
> 
> I support the strongest indistinguishability notion mentioned in (*) above,
> but in my opinion we should provide good description to the users.
> >notion that is by now generally accepted in the crypto community.
> >Meeting it is sufficient to guarantee security against many other forms
> >of attack on confidentiality, which is one of the main reasons we use it.
> >
> >You say that an attack in the sense implied by breaking this notion
> >does not break confidentiality. Can you explain what you mean by
> >>In this paper: http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf,  what
> >>is called confidentiality attack is the known plaintext
> >>differentiality attack where  the attacker has/chooses two plaintexts,
> >>send them to the AES-encryption oracle.  The oracle encrypts one of
> >>them, then sends the ciphertext to the attacker.  After seeing the
> >>ciphertext, the attacker has some success probability of telling which
> >>plaintext  was encrypted and this success probability is in the column
> >>called ³Attack Success Probability² in Table 1.  This attack does not
> >>break confidentiality.
> >>
> >>
> >>system, then making success probability of that attack at 2^(-32) max
> >>is enough. In that case, the Max number of records is around 2^38.
> >>
> >>
> >>
> >>
> >>Regards,
> >>Quynh.
> >>
> >>
> >>
> >>
> >>
> >>
> >>I've just submitted draft-ietf-tls-tls13-14.txt and it should show up
> >>on the draft repository shortly. In the meantime you can find the
> >>editor's copy in the usual location at:
> >>
> >>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 12 Jul 2016 16:33:00 +0000

Unfortunately, that's not quite the right interpretation. The bounds one
obtains depend on both the total amount of data encrypted AND the number
of encryption queries the adversary is allowed to make to AES-GCM under
the (single) target key.

We assumed each record was 2^14 bytes in size to simplify the ensuing
analysis, and to enable us to focus on how the security bounds then depend
on the number of records encrypted. See equation (5) and Table 2 in the
note at 

	http://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf.

In short, the security bound does not necessarily hold for ANY 2^52
encrypted data bytes. For example, if the attacker encrypted 2^52 records
of size 1 (!) then equation (5) would tell us almost nothing useful at all
about security.

Finally, you write "to come to the 2^38 record limit, they assume that
each record is the maximum 2^14 bytes". For clarity, we did not recommend
a limit of 2^38 records. That's Quynh's preferred number, and is
unsupported by our analysis.

Cheers,

Kenny 

On 12/07/2016 16:45, "Scott Fluhrer (sfluhrer)" <[email-masked]> wrote:

>Actually, a more correct way of viewing the limit would be 2^52 encrypted
>data bytes. To come to the 2^38 record limit, they assume that each
>record is the maximum 2^14 bytes.  Of course, at a 1Gbps rate, it'd take
>over a year to encrypt that much data...
>
>>can
>>ciphertexts,
>>block is
>>above,

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 12 Jul 2016 17:04:52 +0000

Hi Kenny, 

>unsupported by our analysis.

What is problem with my suggestion even with the record size being the
maximum value?

Regards,
Quynh.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 12 Jul 2016 17:05:00 +0000

Hi

>security notion than the (old) traditional confidentiality notion.

Well, indeed, I'm somewhat aware of the notion and its emergence over the
years. Indeed, I have had the very real pleasure of writing a few research
papers using indistinguishability-based security notions! Resisting the
temptation to give you chapter and verse on your analysis of the notions
and how to interpret them...

>above, but in my opinion we should provide good description to the users.

OK, I think now we are at the heart of your argument. You support our
choice of security definition and method of analysis after all.

And we can agree that good descriptions can only help.

>That is why I support the limit around 2^38 records.

I don't see how changing 2^24.5 (which is in the current draft) to 2^38
provides a better description to users.

Are you worried they won't know what a decimal in the exponent means?

Or, more seriously, are you saying that 2^{-32} for single key attacks is
a big enough security margin? If so, can you say what that's based on?

Cheers,

Kenny

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 12 Jul 2016 17:12:32 +0000

Hi Kenny, 

>a big enough security margin? If so, can you say what that's based on?

It would not make sense to ask people to rekey unnecessarily. 1 in 2^32 is
1 in 4,294,967,296 for the indistinguishability attack.

Regards,
Quynh. 

>>>Meeting
>>>>is

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 12 Jul 2016 17:17:11 +0000

Hi

>What is problem with my suggestion even with the record size being the

There may be no problem with your suggestion. I was simply trying to make
it clear that 2^38 records was your suggestion for the record limit and
not ours. Indeed, if one reads our note carefully, one will find that we
do not make any specific recommendations. We consider the decision to be
one for the WG; our preferred role is to supply the analysis and help
interpret it if people want that. Part of that involves correcting
possible misconceptions and misinterpretations before they get out of hand.

Now 2^38 does come out of our analysis if you are willing to accept single
key attack security (in the indistinguishability sense) of 2^{-32}. So in
that limited sense, 2^38 is supported by our analysis. But it is not our
recommendation.

But, speaking now in a personal capacity, I consider that security margin
to be too small (i.e. I think that 2^{-32} is too big a success
probability).

Regards,

Kenny

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 12 Jul 2016 17:39:16 +0000

Hi

>1 in 4,294,967,296 for the indistinguishability attack.

I would agree that it does not make sense to ask TLS peers to rekey
unnecessarily. I also agree that 1 in 2^32 is
1 in 4,294,967,296. Sure looks like a big, scary number, don't it?

Are you then arguing that 2^{-32} for single key attacks is a big enough
security margin because we want to avoid rekeying? Then do you have a
specific concern about the security of rekeying? I could see various ways
in which it might go wrong if not designed carefully.

Or are you directly linking a fundamental security question to an
operational one, by which I mean: are you saying we should trade security
for avoiding the "cost" of rekeying for some notion of "cost"? If so, can
you quantify the cost for the use cases that matter to you?

Cheers,

Kenny

---

From: David Benjamin <[email-masked]>
Date: Tue, 12 Jul 2016 17:47:26 +0000

[Changing subject since the other thread is about something else.]

> that rule, since new definition is strict subset of old.

Certainly, whether RSA-PSS and EdDSA are defined in 1.2 or not needs to be
decided. Otherwise, a server may see a 1.3 ClientHello with an RSA-PSS
offer, implement RSA-PSS (because the underlying library can do 1.3), but
select 1.2 (because, for whatever reason, the server is still set to 1.2).
If the client believes RSA-PSS does not exist in 1.2 but the server does,
we will have interop failure. There's a few other analogous situations with
things reversed.

I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exist
in 1.2 because we're not touching the 1.2 registries. But this should be
clarified in the spec. I would actually prefer they stay 1.3-only. I
personally could live with either, but that's because we've backported the
1.3 mechanism to 1.2 (and 1.1 and 1.0 and half[*] of SSL 3.0 with some
minor weirdness). I did intentionally mean for the scheme to be
backportable, but I do not think it should be mandated that implementations
do so.

1.2 and 1.3 signatures have different interfaces. 1.2 is decomposed into a
hash function and a signature algorithm which takes a pre-hashed value. A
1.3 signature scheme is a function that takes a message. This means that,
to backport to TLS 1.2, implementations must remove all pre-hash steps and:

1. For ServerKeyExchange, assemble the client_random || server_random ||
ServerKeyExchange payload and then pass it into the signature scheme.
Current logic probably hashes and then feeds the hash in.

2. Client CertificateVerify in TLS 1.2 messed up. We sign the full
handshake transcript, so there's interactions with the PRF. I've seen
implementations which require signing hash match the PRF hash, sometimes
with a backup SHA-1 hash (NSS), at the cost of hash negotiation being a
mess. I've also seen implementations which decouple them, at the cost of
maintaining the raw handshake buffer (OpenSSL, BoringSSL). Backporting
forces the second choice.

Notably, if backporting EdDSA, there is no rolling hash one can maintain
for CertificateVerify anyway. EdDSA is inherently message-based, which
motivated the 1.3 change. (That and simpler interfaces.)

There is a middle ground: we backport RSA-PSS (then we should assign it in
the 1.2 style and allocate corresponding 1.3-style numbers) and not EdDSA.
I intentionally did not do this. I did not want, many years down the line
when EdDSA certificates actually exist, for implementations to discover the
message-based scheme is trouble. I wanted RSA-PSS to be done in 1.3 style
so any questions about the new scheme would be resolved early.

(We've implemented the message-based scheme and it seems to be just fine.
If you're willing to pay the cost of the backport to all versions, it
actually ends up quite tidy.)

David

[*] SSL 3.0 ServerKeyExchange is compatible with 1.3's API, but SSL 3.0
CertificateVerify signs some complex construction rather than simply a hash.

---

From: David Benjamin <[email-masked]>
Date: Tue, 12 Jul 2016 17:53:34 +0000

> motivated the 1.3 change. (That and simpler interfaces.)

I should add: 1.3 CertificateVerify does not have this problem. One signs,
e.g.:

RSA-PSS-SHA384(padding || context || Hash(HS Context) ||
Hash(resumption_context))

The HS Context can be maintained as a rolling hash of the PRF hash. The
signature scheme internally may use a different pre-hash or no pre-hash at
all and the handshake logic doesn't care.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 12 Jul 2016 17:56:17 +0000

Hi Kenny, 

On 7/12/16, 1:39 PM, "Paterson, Kenny" <[email-masked]> wrote:

>security margin because we want to avoid rekeying?

Because it is safe therefore there are no needs to rekey. I don¹t
recommend to run another function/protocol when there are no needs for it.
I don¹t see any particular reasons for mentioning single key in the
indistinguishability attack here.

>Then do you have a

Regards,
Quynh.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Tue, 12 Jul 2016 17:57:03 +0000

Hi Kenny, 

>of encryption queries the adversary is allowed to make to AES-GCM under

My understanding is that the total is the data complexity limit (counting
block encryptions and queries which are also block encryptions). To be
more precise, then we should count data complexity by number of block
encryptions (encrypting 1 bit is 1 block encryption). But for large data
in TLS, encryption is pretty much with full blocks of plaintexts.

If the attacker has 2^10 encrypted blocks and  is allowed to query another
2^10 encryptions, then the total data is 2^20 because the total of 2^20
block encryptions happens. In TLS, it means that 2^20 AES block
encryptions happen.

Regards,
Quynh.

---

From: "Scott Fluhrer (sfluhrer)" <[email-masked]>
Date: Tue, 12 Jul 2016 18:06:26 +0000

> From: Paterson, Kenny [mailto:[email-masked]]
> Sent: Tuesday, July 12, 2016 1:17 PM
> To: Dang, Quynh (Fed); Scott Fluhrer (sfluhrer); Eric Rescorla; [email-masked]
> >>each record is the maximum 2^14 bytes". For clarity, we did not
> >>recommend a limit of 2^38 records. That's Quynh's preferred number,
> >>and is unsupported by our analysis.
> >
> There may be no problem with your suggestion. I was simply trying to make it
> clear that 2^38 records was your suggestion for the record limit and not ours.
> Indeed, if one reads our note carefully, one will find that we do not make any
> specific recommendations. We consider the decision to be one for the WG;
> our preferred role is to supply the analysis and help interpret it if people
> want that. Part of that involves correcting possible misconceptions and
> misinterpretations before they get out of hand.
> 
> Now 2^38 does come out of our analysis if you are willing to accept single key
> attack security (in the indistinguishability sense) of 2^{-32}. So in that limited
> sense, 2^38 is supported by our analysis. But it is not our recommendation.
> 
> But, speaking now in a personal capacity, I consider that security margin to be
> too small (i.e. I think that 2^{-32} is too big a success probability).

To be clear, this probability is that an attacker would be able to take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential (but incorrect) plaintext, and with probability 2^{-32}, be able to determine that this plaintext was not the one used for the ciphertext (and with probability 0.999999999767..., know nothing about whether his guessed plaintext was correct or not).

I'm just trying to get people to understand what we're talking about.  This is not "with probability 2^{-32}, he can recover the plaintext"

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 12 Jul 2016 18:54:54 +0000

Yup, that's crypto, folks. 

These are the kinds of numbers we should be worrying about for a protocol that will be deployed for decades to billions of people and devices. 

> On 12 Jul 2016, at 19:06, Scott Fluhrer (sfluhrer) <[email-masked]> wrote:
> 
>

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 12 Jul 2016 19:03:07 +0000

Hi,

> On 12 Jul 2016, at 18:56, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
> Hi Kenny, 
> 
> Because it is safe therefore there are no needs to rekey.

Could you define "safe", please? Safe for what? For whom?

Again, why are you choosing 2^-32 for your security bound? Why not 2^-40 or even 2^-24? What's your rationale? Is it just finger in the air, or do you have a threat analysis, or ...?

> I don¹t

Then please read a little further into the note that presents the analysis: a conservative but generic approach dictates that, when the attacker has multiple keys to attack, we should multiply the security bounds by the number of target keys. 

A better analysis for AES-GCM may eventually be forthcoming but we don't have it yet. 

>> you quantify the cost for the use cases that matter to you?

I'd love to have your answer to these questions. I didn't see one yet. What is the cost metric you're using and how does it quantity for your use cases?

Cheers,

Kenny

---

From: "Paterson, Kenny" <[email-masked]>
Date: Tue, 12 Jul 2016 19:09:41 +0000

Hi

> On 12 Jul 2016, at 18:57, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
> Hi Kenny, 
> 
> block encryptions and queries which are also block encryptions).

Yes. And you can approximately convert between them by dividing by the block size (128 bits for AES). 

> To be

Yes. For our analysis, we assume 2^14 bytes per record. This equates to a whole number of AES blocks. You can add one more block per record if you want to, to cater for any rounding up, but it makes only a tiny difference to the final bounds. 

> block encryptions happens. In TLS, it means that 2^20 AES block
I'm not sure I understand this. It's perhaps worth rereading what I wrote just below about why we assume 2^14 bytes per record. 

Cheers,

Kenny

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Jul 2016 22:29:29 +0300

> backportable, but I do not think it should be mandated that implementations

If client signals TLS 1.2 or 1.3 and RSA-PSS and/or EdDSA, it damn better
be able to gracefully deal with server picking on the offer, even after
downnegotiation. Anything else, and you risk interop failures.

Also, neither RSA-PSS nor EdDSA can properly work in TLS 1.1 or older
(no problems there: The server won't be able to pick on the offer).

> to backport to TLS 1.2, implementations must remove all pre-hash steps and:

The current signature algorithm numbers are messed up. I would have assigned
0x0404, 0x0504 and 0x0604 for RSA-PSS, and some 0x00yy numbers for EdDSA.

(That way the signature algorithms have proper hash designations, and yes
0x00 is hash designation for "unhashed").
 
> Current logic probably hashes and then feeds the hash in.

If one has proper signature primitive, it takes a message and internally
hashes it the way needed.

> forces the second choice.

By the time CertificateRequest is sent, the server knows the final
protocol, so it can omit algorithms it knows it can't handle. Also,
the client picks the actual algorithm, so it too can avoid algorithms
it can't handle. So client auth isn't the interop hazard server auth
is.

> motivated the 1.3 change. (That and simpler interfaces.)

Well, proper crypto libs only have message-based signature APIs anyway
(because hash-based ones are trouble).
 
> so any questions about the new scheme would be resolved early.

Well, RFC4492bis is likely have EdDSA, in way that is compatible with
TLS 1.3...

> actually ends up quite tidy.)

Yeah, it seems annoying with TLS 1.2 Client CertificateVerify, but
there either side can decide just not to support it. No such luck
with clients that implement the algorithm for server certificates in
any version.

-Ilari

---

From: Atul Luykx <[email-masked]>
Date: Tue, 12 Jul 2016 21:50:03 +0200

> To be clear, this probability is that an attacker would be able to
> take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential
> (but incorrect) plaintext, and with probability 2^{-32}, be able to
> determine that this plaintext was not the one used for the ciphertext
> (and with probability 0.999999999767..., know nothing about whether
> his guessed plaintext was correct or not).

You need to be careful when making such claims. There are schemes for 
which when you reach the birthday bound you can perform partial key 
recovery.

The probabilities we calculated guarantee that there won't be any 
attacks (with the usual assumptions...). Beyond the bounds, there are no 
guarantees. In particular, you cannot conclude that one, for example, 
loses 1 bit of security once beyond the birthday bound.

Atul

On 2016-07-12 20:06, Scott Fluhrer (sfluhrer) wrote:
> To be clear, this probability is that an attacker would be able to
> take a huge (4+ Petabyte) ciphertext, and a compatibly sized potential
> (but incorrect) plaintext, and with probability 2^{-32}, be able to
> determine that this plaintext was not the one used for the ciphertext
> (and with probability 0.999999999767..., know nothing about whether
> his guessed plaintext was correct or not).
> 
> I'm just trying to get people to understand what we're talking about.
> This is not "with probability 2^{-32}, he can recover the plaintext"
> 
> 
>> 
>> Regards,
>> 
>> Kenny
>

---

From: David Benjamin <[email-masked]>
Date: Tue, 12 Jul 2016 19:53:41 +0000

> downnegotiation. Anything else, and you risk interop failures.

Right, there is a risk of interop failures if two implementations disagree
on whether the algorithms exist in 1.2. Since getting these algorithms into
1.2 is not that important, I want everyone to standardize on the easier
option (that is, they do *not* exist in 1.2). Otherwise we risk some
implementations backporting (because the spec says to) and some not
(because it is easier not to).

> 0x00 is hash designation for "unhashed").

TLS 1.3 SignatureScheme intentionally does away with the decomposition. It
thinks of a "signature algorithm" at the level of messages, which means
implementations shouldn't care about this.

This also gives us more breathing room to allocate ed25519-style IDs (which
I would like to be the norm, rather than parametrizing everything). We get
most of our 2^16 space rather than just 2^8.

> hashes it the way needed.

Yup, that's why TLS 1.3's version looks the way it does. But if one has
such a primitive, one shouldn't care about how the numbers are decomped
(above). :-)

> it can't handle. So client auth isn't the interop hazard server auth

When we first added TLS 1.2 to Chrome via NSS, we hit exactly that interop
hazard. Clients don't know a priori which hash functions the server will
accept and may be using some crappy smartcard. The original implementation
only accepted the PRF hash (SHA-256) and we ran into both servers and
client smartcards that could only sign SHA-1. As a result, NSS maintains a
rolling SHA-1 "backup hash" here.

(The failure mode was, of course, everyone's favorite TLS version fallback.)

I am sure that, were we still using NSS when we added AES_256_GCM (SHA-384
PRF), we would have hit more problems with smartcards that can only sign
SHA-256.

But this is all sort of beside the point. The way to avoid this interop
hazard is to maintain the full handshake buffer which is also how you
backport. :-) I'm more worried about implementations which don't do the
backport because it's more work or they don't want to pay the handshake
buffer.

> Well, RFC4492bis is likely have EdDSA, in way that is compatible with

(s/TLS 1.3/TLS 1.2/?)

Yeah, I don't think defining it for 1.2 makes much sense. I expect 1.3 will
get deployed much faster than EdDSA PKIs.

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Jul 2016 22:55:06 +0300

> it can't handle. So client auth isn't the interop hazard server auth

There actually are TLS stacks in dev that have TLS 1.2 client
authentication on will-not-implement-list (for reasons totally unrelated
to "message-based signatures") but are willing to consider or implement
TLS 1.3 client authentication (these are done by authors who actually
care about security[1], and know just how dangerous "crap" is).

(Oh, at least two of those have backend signature APIs that actually
are message-based for all signatures).

[1] To the point of willfully ignoring "MUST" or "MUST NOT" requirements
that conflict on security. E.g. unsafe MTIs won't be implemented.

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 12 Jul 2016 23:17:07 +0300

> (because it is easier not to).

Unfortunately, the way things are, it is both easier and way safer to
say that they *do* exist in TLS 1.2, at least for server signatures
(one can leave the crazy mess that is client signatures[1]).

And here RSA-PSS is even worse hazard than EdDSA. EdDSA at least
requires its own EE certs, RSA-PSS works with standard RSA EE
certs that are widespread. Have a TLS 1.3-capable server that
doesn't check versions (easy enough[2]) and have it capped to TLS 1.2
by something (either misconfig or API issues, no end of those
kind of servers) and there you go...

That is, if client advertises EdDSA or RSA-PSS, it MUST be able to
verify those, even after downnegotiation to TLS 1.2. If it doesn't,
it MUST NOT advertise them, even in TLS 1.3 ClientHello.

[1] How many borked/buggy servers there are that say they support
X, but fail if you try to use X? Outside known trouble like mixing
and matching curves and hashes in ECDSA?

[2] There is actually very simple way to implement things that seems
to work, only it blows up when client that claims it supports
something it doesn't comes along...

-Ilari

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 12 Jul 2016 15:31:21 -0500

> Did a readthrough, here's a bunch of comments (didn't check the

Should we bulk-open issues for these so they don't get lost?  I will
only cherry-pick a couple to reply to.

It probably ought to be, yes.

> TLS 1.2 ticket "maybe resume" craziness (except this would be even

I feel like we had discussed what the resumption ciphersuite should be
previously, but I don't seem to be able to find it in my mail archives.

> or not? E.g. if client didn't indicate support for x448, can the server

Requiring filtering would prevent the client from learning when the
server supports new schemes, but having the server not filter would
likely end up with the server "always" sending a big pile of stuff even
if the client has no idea that those schemes even exist.  So, on the
balance, I would go with filtering.

> pick smallest you support, if you have, pick the one it selected

It does make it clear that things are only as secure as the weakest
algorithm they will accept ... but stateless clients will also always
get that weakest link.  (Okay, "smallest" does not necessarily equal
"weakest", but still.)  With guidance on not supporting silly things,
this algorithm does not seem too crazy...

>> tolerance of the time since the ticket was issued (see {{replay-time}}).

It would be good to not repeat the mistake that is the 5-minute replay
window in Kerberos.  (So, shall we make "small tolerance" a concrete
value or otherwise give guidance?  5 seconds?  4xRTT? other?
But, IIRC, this check does not require absolute time agreement between
peers, only that their clocks advance at a similar rate.  If your clock
steps because you slept your laptop and you have to fall back to a full
handshake, oh well.

> reject 0-RTT if that validation fails would be good here...

Definitely.

> Oh, still trial decryption... Got it. 

I had managed to previously forget how we ended up deciding on trial
decryption, but it basically was dkg commenting in the room at Buenos
Aires "are we writing a security protocol or a protocol that is
convenient to implement?" [with respect to the privacy/leakage from
having the alert or other signal be unencrypted].

> I don't think variations in clocks are minimal...

Just to check: you mean the rate at which clocks advance, and not the
absolute number reported as the time?

> (Oh, and have fun with leap seconds!)

It only matters how big the skew is relative to the acceptance window
and how long the ticket is valid for.  Which brings us back to what the
acceptance window is measured in...

> extensions are bounded by client-supported ones.

You would have an explicit whitelist of all (including encrypted)
extensions for the server, so that it chokes when a client starts
sending a new one?  Or just that it would not be considered for further
processing [and potential inclusion in ServerHello]?

> random numbers, given that anything else is fraught with peril.

Sadly, there is a vocal minority of software implementors that insist
that the OS service is too slow and write their own.  But I agree this
section needs some work; I may be able to contribute some text.

> I think properties of the exporter should be covered as well:

I agree (but am unlikely to be able to contribute text).

-Ben

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 13 Jul 2016 00:07:33 +0300

> It probably ought to be, yes.

If the field is allowed to contain some ciphersuite with wrong key exchange
type, it takes sniffing extensions from ServerHello and EncryptedExtensions
to figure out what the actual ciphersuite is. And knowing the key exchange
type is rather important in not getting hit by SMACK.
 
> previously, but I don't seem to be able to find it in my mail archives.

AFAIK, the ciphersuite with the same protection and PRF, but some PSK
or GDHE-PSK key exchange type.

There is well-defined function from (kextype,protection,prfhash) into
ciphersuite (or that no such ciphersuite exists).

> balance, I would go with filtering.

What would the client do with unknown groups anyway? Dump a message
to log?
 
> this algorithm does not seem too crazy...

Well, what client accepts is separate question to its speculative
guesses for performance improvement. And for the first, there is
supported_groups. key_share is not meant to be xmas tree!

> steps because you slept your laptop and you have to fall back to a full

In one piece of code I wrote, I pulled +-15s maximum (config can have
tighter limits) out of thin air...

And, actually, since failing 0-RTT time check is just 1-RTT delay
(since in proper implementations it is not a fatal error).
 
> having the alert or other signal be unencrypted].

I thought they had switched to something else, but apparently not...
 
> absolute number reported as the time?

Correct. I should check the computers I have for what the tickrate
approximately is (one curious observation: rebooting computer changes
the tickrate(!)). I think I estimated 140ms/day drift for one of
those (the others can be way worse). 

However, the rate of change of the rate (2nd derivate of time reported
relative to "true time" (one can for all practical purposes ignore
SR and GR here)) should be small.
 
> acceptance window is measured in...

IIRC, maximum ticket validity is 7 days (but for some crappier clocks,
that can be lots of drift).

But likely TCP delays and such can cause bigger errors than slightly-
bad clocks.

> processing [and potential inclusion in ServerHello]?

The opposite way: I would have client choke if server sends it extension
outside those lists (TLS 1.3 clients are already supposed to choke if
server sends them extension they don't know about, this is only extending
it to per-messages lists).

> section needs some work; I may be able to contribute some text.

I think "SHOULD" would be suitable.
 
> > - Are values for different labels/contexts intended to be computationally

Oh, and stick that it stays constant for the duration of the
connection as well...

-Ilari

---

From: David Benjamin <[email-masked]>
Date: Tue, 12 Jul 2016 21:13:43 +0000

> kind of servers) and there you go...

That's fair. If you do the backport version, then you do have to go out of
your way to do the version check.

I guess the question is what other implementors intend then? We've actually
done the backport on our end. Perhaps my guess that not everyone will do
this is wrong.

> it MUST NOT advertise them, even in TLS 1.3 ClientHello.

Well, we could define that EdDSA/RSA-PSS in TLS 1.2 doesn't exist and then
spec-wise we're fine. The question is just which we think will cause fewer
interop issues.

Either way, worst case, we'd just end up in an awkward state where, when
signing, one does not pick RSA-PSS in 1.2 but when verifying, one should
accept it. Not the end of the world. I might just go ahead and do that
anyway so I don't have to care about this issue...

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Jul 2016 14:20:21 -0700

> only cherry-pick a couple to reply to.

I opened one giant issue because I haven't gone through this yet

If you want to open individual issues that you think are meritorious that
woul dbe fine

-Ekr

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 12 Jul 2016 19:41:02 -0500

> What would the client do with unknown groups anyway? Dump a message

Basically.  One could contrive an example where the client software knew
about something but didn't normally send it, but that seems too
contrived to care about.

> (since in proper implementations it is not a fatal error).

Right, so we can be relatively stringent in our guidance.

> SR and GR here)) should be small.

Hmm, I would expect this second derivative to be sensitive to things
like the temperature of the oscillator (and thus not always small).

> But likely TCP delays and such can cause bigger errors than slightly-

Hence my question about whether some multiple of (estimated) RTT would
be reasonable.

> it to per-messages lists).

That certainly makes sense.  I thought you also wanted a whitelist for
the server to use, and wasn't sure how that would work.

> I think "SHOULD" would be suitable.

Sure.

-Ben

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 13 Jul 2016 10:55:24 +0000

Good morning Kenny,

On 7/12/16, 3:03 PM, "Paterson, Kenny" <[email-masked]> wrote:

>>>>> Or, more seriously, are you saying that 2^{-32} for single key
>>>>>attacks
>>>>> is
>>>> It would not make sense to ask people to rekey unnecessarily. 1 in
>>>>2^32
>>>> is
>Again, why are you choosing 2^-32 for your security bound? Why not 2^-40
>or even 2^-24? What's your rationale? Is it just finger in the air, or do
>you have a threat analysis, or ...?

I said it is safe because the chance of 1 in 4,294,967,296 practically
does not happen. I am not interested in talking about other numbers and
other questions. 

>Then please read a little further into the note that presents the
>analysis: a conservative but generic approach dictates that, when the
>attacker has multiple keys to attack, we should multiply the security
>bounds by the number of target keys.
>
>I'd love to have your answer to these questions. I didn't see one yet.
>What is the cost metric you're using and how does it quantity for your
>use cases?

Again, I am not interested in other questions. I suggested the number
about 2^38 records because it is a safe data bound because Eric put in his
tls 1.3 draft the number 2^24.5 which is unnecessarily small.

Your paper is a nice one which gives users good information about choices.

Regards,
Quynh.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 13 Jul 2016 11:09:36 +0000

Hi Kenny, 

>bounds by the number of target keys.

I don’t think multiple target keys help the data complexity in the context
of TLS here for the distinguishing attack. Let’s look at two situations in
multiple keys in TLS.

1) Different data sets with different keys and their respective bound such
as 2^38 records: (k1, dataset1, 2^38),…..(k10, dataset10, 2^38).

The attacker has 10 times more chances of success with 10 times more data
complexity.

2) The same data set with different keys: (k1, dataset, 2^38),…., (k10,
dataset, 2^38).

Even though, the same data set is used with different keys, the data
complexity is 10 times more in order for the attacker to have 10 times
more likely to succeed.

Regards,
Quynh.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 13 Jul 2016 11:14:13 +0000

Hi Atul, 

>loses 1 bit of security once beyond the birthday bound.

How can one use the distinguishing attack with the data complexity bound I
suggested for recovering 1 bit of the encryption key in the context of TLS
? 

Regards,
Quynh.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 13 Jul 2016 13:51:28 +0200

> processing [and potential inclusion in ServerHello]?

I'd rather not see a mechanism that will introduce TLS extension intolerance
in compliant implementations.

IMNSHO this is the uncommon situation where a blacklist is the correct
solution
-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

---

From: Atul Luykx <[email-masked]>
Date: Wed, 13 Jul 2016 14:30:25 +0200

Hey Quynh,

> suggested for recovering 1 bit of the encryption key in the context of 
You cannot recover any bits of the encryption key unless you attack AES.

No-one, as far as I know, has analyzed what kind of attacks one can 
perform against GCM around and beyond the birthday bound (except for the 
forgery attacks, which require repeated nonces or known forgeries). 
However, for CTR mode, the underlying encryption of GCM, David McGrew 
typed up a document describing an attack one could perform to recover 
information about the plaintext:
http://eprint.iacr.org/2012/623
He describes it for 64 bit block ciphers, but the attacks work equally 
well for 128 bit block ciphers, at a higher data complexity of course.

Basically, there are a lot of unknowns, and it could be that the bounds 
you recommend will be good enough in practice. However, it's important 
to be clear about the risks involved in venturing into unknown 
territory.

Atul

On 2016-07-13 13:14, Dang, Quynh (Fed) wrote:
>>>> Indeed, if one reads our note carefully, one will find that we do 
>>>> not
>>>> make any
>>>> our preferred role is to supply the analysis and help interpret it 
>>>> if
>>>> people
>>>> attack security (in the indistinguishability sense) of 2^{-32}. So 
>>>> in
>>>> that limited

---

From: Watson Ladd <[email-masked]>
Date: Wed, 13 Jul 2016 06:26:06 -0700

On Wed, Jul 13, 2016 at 5:30 AM, Atul Luykx <[email-masked]> wrote:
> No-one, as far as I know, has analyzed what kind of attacks one can perform
> against GCM around and beyond the birthday bound (except for the forgery
> attacks, which require repeated nonces or known forgeries). However, for CTR
> mode, the underlying encryption of GCM, David McGrew typed up a document
> describing an attack one could perform to recover information about the
> plaintext:
> He describes it for 64 bit block ciphers, but the attacks work equally well
> for 128 bit block ciphers, at a higher data complexity of course.
>
> Basically, there are a lot of unknowns, and it could be that the bounds you
> recommend will be good enough in practice. However, it's important to be
> clear about the risks involved in venturing into unknown territory.
>
> Atul

Furthermore the cost of avoiding this is trivial. The rekeying
mechanism has been designed to have minimal code complexity.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: "Dang, Quynh (Fed)" <[email-masked]>
Date: Wed, 13 Jul 2016 13:58:44 +0000

On 7/13/16, 9:26 AM, "Watson Ladd" <[email-masked]> wrote:

>>perform
>>well
>>you

GCM with data complexity of about 3^38 records is not vulnerable to that
plaintext recovery attack. Therefore, there are no needs to rekey before
that data complexity is reached.

For counter-mode, I think the attack works if there is a large set of
known plaintexts. In protocols such as TLS and Ipsec, there are known
plaintexts, but I don¹t think the amount of known plaintexts (even though
the amount of encrypted repeated-plaintexts can be big) is enough to
create risk for AES_128 by the targeted plaintext recovery attack. A known
plaintext can be encrypted multiple times with different keys, not with
the same key. 

Regards,
Quynh.

---

From: "Paterson, Kenny" <[email-masked]>
Date: Wed, 13 Jul 2016 17:57:09 +0000

Hi

>On 7/12/16, 3:03 PM, "Paterson, Kenny" <[email-masked]> wrote:

<snip>

>does not happen. I am not interested in talking about other numbers and

OK, then I think we're done here.

>tls 1.3 draft the number 2^24.5 which is unnecessarily small.

Again, look like we're done here.

>Your paper is a nice one which gives users good information about choices.

Thanks, I'm glad you found it useful.

Cheers

Kenny

---

From: David McGrew <[email-masked]>
Date: Mon, 18 Jul 2016 17:11:15 -0400

Hi Quynh,

> On Jul 13, 2016, at 9:58 AM, Dang, Quynh (Fed) <[email-masked]> wrote:
> 
> 
> 

That’s right, as long as the number of 16-byte blocks per record is guaranteed to be significantly below 2^26.  

> create risk for AES_128 by the targeted plaintext recovery attack.

What is especially cool about counter mode encryption is how its real world security degrades more gracefully than CBC mode encryption.  I am not sure that the FSE paper did a good job of saying it in English as opposed to math (except for the last sentence of Section 4), but even though CTR may be just as distinguishable as CBC after some amount of known plaintext is encrypted, counter mode in practice gives away much less information.     

best

David

> A known

---

From: Atul Luykx <[email-masked]>
Date: Tue, 19 Jul 2016 08:26:47 +0200

> What is especially cool about counter mode encryption is how its real
> world security degrades more gracefully than CBC mode encryption.  I
> am not sure that the FSE paper did a good job of saying it in English
> as opposed to math (except for the last sentence of Section 4), but
> even though CTR may be just as distinguishable as CBC after some
> amount of known plaintext is encrypted, counter mode in practice gives
> away much less information.

Just to be precise, no attack has been found which illustrates that CTR 
mode's security degrades like CBC's. Nevertheless, it might be possible 
to formalize your intuition.

Atul

On 2016-07-18 23:11, David McGrew wrote:
>>> On Wed, Jul 13, 2016 at 5:30 AM, Atul Luykx 
>>> <[email-masked]>
>>> wrote:
>>>> Hey Quynh,
>>>> 
>>>>> suggested for recovering 1 bit of the encryption key in the context 
>>>>> of
>>>>> TLS
>>>>> ?
>>>> 
> That’s right, as long as the number of 16-byte blocks per record is
> guaranteed to be significantly below 2^26.
> 
>> 
> What is especially cool about counter mode encryption is how its real
> world security degrades more gracefully than CBC mode encryption.  I
> am not sure that the FSE paper did a good job of saying it in English
> as opposed to math (except for the last sentence of Section 4), but
> even though CTR may be just as distinguishable as CBC after some
> amount of known plaintext is encrypted, counter mode in practice gives
> away much less information.
> 
> best
> 
> David
> 
>> A known
>>>>>> attacks (with the usual assumptions...). Beyond the bounds, there 
>>>>>> are
>>>>>> no
>>>>> suggested for recovering 1 bit of the encryption key in the context 
>>>>> of
>>>>> TLS
>>>>> ?
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> Quynh.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> 
>>>>>> Atul
>>>>>> 
>>>>>>>>> On 7/12/16, 12:33 PM, "Paterson, Kenny" 
>>>>>>>>> <[email-masked]>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Finally, you write "to come to the 2^38 record limit, they 
>>>>>>>>>> assume
>>>>>>>> that
>>>>>>>>> What is problem with my suggestion even with the record size 
>>>>>>>>> being
>>>>>>>> the
>>>>>>>>> maximum value?
>>>>>>>> 
>>>>>>>> There may be no problem with your suggestion. I was simply 
>>>>>>>> trying to
>>>>>>>> make it
>>>>>>>> clear that 2^38 records was your suggestion for the record limit 
>>>>>>>> and
>>>>>>>> not ours.
>>>>>>>> specific recommendations. We consider the decision to be one for 
>>>>>>>> the
>>>>>>>> WG;
>>>>>>>> want that. Part of that involves correcting possible 
>>>>>>>> misconceptions
>>>>>>>> and
>>>>>>>> Now 2^38 does come out of our analysis if you are willing to 
>>>>>>>> accept
>>>>>>>> single key
>>>>>>>> But, speaking now in a personal capacity, I consider that 
>>>>>>>> security
>>>>>>>> margin to be

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 19 Jul 2016 06:58:52 +0000

David McGrew <[email-masked]> writes:

>What is especially cool about counter mode encryption is how its real world
>security degrades more gracefully than CBC mode encryption.

Uhh... how does CTR "degrade gracefully" compared to CBC?  With CTR, any kind
of problem with the IV/CTR leads to a catastrophic loss of security.  With CBC,
even the worst-case IV abuse you can apply, setting it to all zeroes, just
degrades the mode to ECB.

(There have been a number of instances of CTR, or at least GCM, failures
already, and I doubt we've seen the last of it.  It's RC4 all over again).

Peter.

---

From: David McGrew <[email-masked]>
Date: Tue, 19 Jul 2016 05:47:48 -0400

Hi Peter,

> On Jul 19, 2016, at 2:58 AM, Peter Gutmann <[email-masked]> wrote:
> 
> Uhh... how does CTR "degrade gracefully" compared to CBC?  

I should have said: “degrades more gracefully as the number of known plaintext blocks increases to, and beyond, the birthday bound”.  

> With CTR, any kind

Right, but that’s a different topic.

David

---

From: David McGrew <[email-masked]>
Date: Tue, 19 Jul 2016 05:58:54 -0400

HI Atul,

> On Jul 19, 2016, at 2:26 AM, Atul Luykx <[email-masked]> wrote:
> 
> Just to be precise, no attack has been found which illustrates that CTR mode's security degrades like CBC’s.

I either don’t understand the sentence, or I disagree with it.  Both CTR and CBC are only secure up to the birthday bound, and are distinguishable at or beyond that bound.   

> Nevertheless, it might be possible to formalize your intuition.
> 

Agreed, and what is needed is a measure of the expected amount of information an attacker has about the (unknown) target plaintext, which would be larger in the CBC case than the CTR case.   This is interesting, but of course, we should stick with the standard definition of indistinguishability as our security criterion.

Hope this doesn’t sound like nit picking; I just want to make sure that no one thinks I am suggesting that it is OK to use encryption systems that are distinguishable.

best,

David

---

From: Atul Luykx <[email-masked]>
Date: Tue, 19 Jul 2016 12:12:45 +0200

Hey David,

On 2016-07-19 11:58, David McGrew wrote:
> I either don’t understand the sentence, or I disagree with it.  Both
> CTR and CBC are only secure up to the birthday bound, and are
> distinguishable at or beyond that bound.
> 

Sounds good; I was just clarifying the possibility that CTR could be as 
vulnerable as CBC beyond the birthday bound in practice, addressing the 
following sentence:
>> counter mode in practice gives away much less information.
But you're right, I wasn't very clear.

> Agreed, and what is needed is a measure of the expected amount of
> information an attacker has about the (unknown) target plaintext,
> which would be larger in the CBC case than the CTR case.   This is
> interesting, but of course, we should stick with the standard
> definition of indistinguishability as our security criterion.
> 
> Hope this doesn’t sound like nit picking; I just want to make sure
> that no one thinks I am suggesting that it is OK to use encryption
> systems that are distinguishable.
> 
> best,
> 
> David
> 
>> Atul