Daniel Migault | 27 May 22:17 2016

draft-tls-tls13 - comments on section 4.8.1 Digital Signature


I have a few comments while reading 4.8.1 Digital Signature of draft-tls-tls13.Hope it helps.


Comment a)
"In previous versions of TLS, the ServerKeyExchange format meant that attackers can obtain a signature of a message with a chosen, 32-byte prefix. "

My understanding is that the ServeKeyExchange format defines the bits exchanged between the TLS Client and the TLS Server. I think the attack vector is more coming from how the signatures are computed. I would rather propose something like:

"In previous version of TLS, the signature of the ECDH or EDH public key is performed by concatenating the client random, the server random to the public keys. The concatenation is hash and then signed. As the client random is chosen by the TLS CLient, such design allows an attacker to obtain a signature of a message with a chosen 32-byte prefix."

Comment b)

"Because TLS 1.3 servers are likely to also implement prior versions, the contents of the element always start with 64 bytes of octet 32 in order to clear that chosen-prefix.

I think some additional steps need to be explicitly specified. I am not completely sure of what is being signed. 
    a) padding + context + H(client.random + server + random + ECDHE/DHE Params)
    b) padding + context + client.random + server + random + ECDHE/DHE Params
    c) padding + context + ECDHE/DHE Params
   d) something else

I assume that is a) in which case, the reason for choosing this format is to constraint changes between TLS versions at the signing module. In addition, if the correct scheme is a) maybe some additional text or reference could explain why the padding and context solves this problem. By prepending a fixed padding and some context, to the output of the hash function, the TLS Client does not control the input that is signed as cryptographic hash function are expected to be non-invertible.

Comment c)

"A single 0 byte is appended to the context to act as a separator."

When describing how the input to be signed is built, it may be clearer to emphasize that string ends with 0, whihc leads to a "00" separator. I would propose to add something like: "As the string ends with a "0" byte, the binary representation will results in two zero bytes."

Comment d)

It would help the reader to add that “Example” is represented in hexa by 4578616d706c650 with the end of string character.


TLS mailing list
TLS <at> ietf.org
internet-drafts | 27 May 19:19 2016

I-D Action: draft-ietf-tls-ecdhe-psk-aead-00.txt

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-00.txt
	Pages           : 7
	Date            : 2016-05-27

   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:

There's also a htmlized version available at:

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:
Sean Turner | 27 May 16:55 2016

adopted: draft-mattsson-tls-ecdhe-psk-aead

I appears that we’ve got enough consensus/interest to adopt draft-mattsson-tls-ecdhe-psk-aead
based on this thread:

Note that this draft will be published using new the IANA registrations rules we’ve discussed so it’ll
probably get pinned waiting for the TLS1.3 draft to be published.  Also, we should probably just go ahead
and get the early IANA code point assignment done, but we’ll do that in another thread.


If draft-mattsson-tls-ecdhe-psk-aead works as a draft name let us know and one of us can pre-approve the
draft so we can start moving this draft through the process.


TLS mailing list
TLS <at> ietf.org
Sean Turner | 27 May 16:55 2016

adopted: draft-shore-tls-dnssec-chain-extension

It appears that we’ve got enough consensus/interest to adopt
draft-shore-tls-dnssec-chain-extension based on this thread:

We're hoping that we can maintain focus and get this extension published quickly.


If draft-ietf-tls-dnssec-chain-extension works as a draft name let us know and one of us can pre-approve
the draft so we can start moving this draft through the process.


TLS mailing list
TLS <at> ietf.org
Martin Thomson | 25 May 23:55 2016

Re: Asking for certificate authentication when doing 0-RTT

I think that there are four levels of continuity that make sense here :

1. None. Anthony can change.
2. Server name. I.e. SNI stays constant.
3. Public key (and SNI) stays constant.
4. The certificate stays the same.

The use case of short-lived certs is served by 2. 3 might also work. I think that 4 is too restrictive, as we have established. 1 just doesn't seem plausible, since the psk_identity will be cached against a name in almost every case I can imagine.

On 26 May 2016 01:47, "Benjamin Kaduk" <bkaduk <at> akamai.com> wrote:
On 05/24/2016 11:18 PM, Martin Thomson wrote:
> On 24 May 2016 at 19:06, Kyle Nekritz <knekritz <at> fb.com> wrote:
>> What is the rationale for restricting a change in certificate? If the server has a new certificate that the client would accept with a full handshake, what threat is added by also accepting that certificate with a PSK handshake?
> This was a request from David Benjamin.  But then all the things you
> mention are why I think that it might have been a bad idea.  I think
> that the idea was to avoid unnecessary changes.  Changes that might
> regress the security decisions made originally.  It was the most
> conservative choice without thinking about the problem too much.
> However, if we model this as new connection + 0-RTT stuff, then I
> think that we are good.  Probably.  If anyone disagrees it would be
> good to hear that.

It seems like it's kind of messy either way -- if the cert changes, the
client has to check the chain of course, but it also ought to confirm
that it's still talking to "the same party" [0] that it was before, so
it is not sending data to someplace it didn't expect.  A scenario where
an attacker can break the 0-RTT crypto and swap in an
attacker-controlled certificate is admittedly a bit far-fetched (other
things would probably be broken, too), but what about a mis-configured
shared host that can accept the 0-RTT for the original site but then
mistakenly presents a cert for a different site that is hosted there
[and sends the data off to the wrong backend]?

If we prevent the cert from changing, then yes there's the added
complexity for deploying cert updates.

It's not even clear that doing a 0-RTT reject when the server wants to
change cert would fix everything, though it might help some.


[0] Somehow I don't think there's a good way to express the "same party"
check that works everywhere.
TLS mailing list
TLS <at> ietf.org
Dang, Quynh (Fed | 24 May 17:20 2016

Comments on nonce construction and cipher text size restriction.

Hi Eric, 

1. For this text:  "plus the length of the output of the signing algorithm. " in the last paragraph of Section 4.8.1, did you mean "plus the output of the signing algorithm.” ?

2. "The length (in bytes) of the following TLSCiphertext.fragment. 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. " . There could be a cipher that generates ciphertext longer than plaintext in some cases plus the tag. If the tag was 256 bits, then this requirement would disallow that cipher unnecessarily when a record size is 2^14. 

3. "The padded sequence number is XORed with the static client_write_iv or server_write_iv, depending on the role.” I think the ivs are not needed. 

4. The current way nonce is specified would disallow ciphers that use any other ways of generating the nonce such as random nonces.

Regards, Quynh.

TLS mailing list
TLS <at> ietf.org
The IESG | 23 May 18:34 2016

Document Action: 'Transport Layer Security (TLS) False Start' to Informational RFC (draft-ietf-tls-falsestart-02.txt)

The IESG has approved the following document:
- 'Transport Layer Security (TLS) False Start'
  (draft-ietf-tls-falsestart-02.txt) as Informational RFC

This document is the product of the Transport Layer Security Working

The IESG contact persons are Stephen Farrell and Kathleen Moriarty.

A URL of this Internet Draft is:

1. Summary

"False Start” was an attempt to reduce the latency impact of HTTPS based on the simple premise that the
client send application data earlier in the handshake; to be precise clients send application data
before they have received and verified the server's "Finished” message.  Initial measurements showed
a 30% reduction in latency [0] I could paraphrase more of s2, but the authors explained the timing and the
implications at the end of s2.

Note that this “experiment” was supported by Chrome, FF, IE, OpenSSL, NSS, and others. Some
additional details:

- Chrome 20 disable it except for sites that enabled NPN.

- Firefox has (or at some point had) an NPN requirement to enable False Start.

- Safari as an additional example without the NPN requirement:

- While there were patches to enable False Start with OpenSSL, it's not clear it was ever part of an official

As far as where you should point your fingers:
- Sean Turner is the document shepherd, and;
- Stephen Farrell is the responsible Area Director.

2. Review and Consensus

There wasn’t a whole lot of discussion, primarily because "False Start” the implementation issues
were worked out by the browsers and the WG didn’t adopt this draft until long after (Nov-2014).  The draft
was adopted because it documents existing practices and provides security considerations [0]; the
comments in the WG adoption thread were incorporated in the -01 WG version.  The WG’s deliberations
resulted in a number of changes that more accurately reflect deployments (i.e., dropping server-side
False Start) as well as restricting its use to pre-TLS1.3 (see s5.2) and cipher suites (see s5.3).

One reviewer wanted all (FF-)DHE cipher suites removed because they believe that the downgrade
protections defined in [1] are in adequate. To solve address this issue, the “False Start” draft
requires whitelists as well as large groups/curves.

[0] https://mailarchive.ietf.org/arch/msg/tls/RLklpxmZ3BQRBIqWgfeUcCLhgx0
[1] https://datatracker.ietf.org/doc/draft-ietf-tls-negotiated-ff-dhe/

RFC Editor Note

 Please change the intended status in the header to "Informational"
 I don't believe any other text changes are needed. (The IESG and
 authors figured that informational was better during IESG eval.)

TLS mailing list
TLS <at> ietf.org
Eric Rescorla | 22 May 21:45 2016

TLS 1.3 draft 13.


I just uploaded draft-13. Changelog appended at the bottom of this

The following nontrivial issues are outstanding:

- How to encrypt post-handshake messages (post-handshake client auth,
  NewSessionTicket, etc.). I'm having a discussion now with the
  cryptographers about this.
- Allowing multiple session tickets in NewSessionTicket
  but please take a look.

- The rules for how closely extensions need to match in 0-RTT. I am
  starting to think that Ilari is right that the current "check
  everything for match" is too strict, so expect a new PR for this
  in the next few days.

I want to resolve these this week and then publish -14 soon after.


- Allow server to send SupportedGroups.

- Remove 0-RTT client authentication

- Remove (EC)DHE 0-RTT.

- Flesh out 0-RTT PSK mode and shrink EarlyDataIndiation

- Turn PSK-resumption response into an index to save room

- Move CertificateStatus to an extension

- Extra fields in NewSessionTicket.

- Restructure key schedule and add a resumption_context value.

- Require DH public keys and secrets to be zero-padded to the size
  of the group.

- Remove the redundant length fields in KeyShareEntry.

- Define a cookie field for HRR.

TLS mailing list
TLS <at> ietf.org
Ilari Liusvaara | 22 May 16:22 2016

PR ¤468: Cookie for hrr

Looking at PR #468:
- It isn't at all obvious how to use it for stateless rejection.
- It is even less obvious how to recover (not causing non-retryable
  fault) from bad cookie (e.g. expired) remembered from previous

There are some tricks for both, but with latter, the 255-byte
cookie space can become quite cramped...

I think it would be easier if either:
- Cookies could not be remembered across connections.
- HRR and EE cookies had separate slots those go to in CH.

(Of course, neither of those solves the "failed 0-RTT" case...)

Also, some clients do burst connects, where multiple TLS
connections are connected in parallel. Through quite frequently
these would be pure-PSK, keyed off one master GDHE-CERT

Eric Rescorla | 22 May 00:16 2016

Issue 472: Remove redundant warning alerts

  Therefore, warning alerts are not very useful when
  the sending party wants to continue the connection, and thus are sometimes
  omitted. For example, if a party decides to accept an expired certificate
  (perhaps after confirming this with the user) and wants to continue the
  connection, it would not generally send a "certificate_expired" alert.

It would probably be simpler to require that alerts either be warning or fatal and that
the only warning alerts are the "Closure Alerts" specified in
rather than expect people to handle some warning version of the Error Alerts.


TLS mailing list
TLS <at> ietf.org
Eric Rescorla | 22 May 00:11 2016

Issue 471: Relax requirement to invalidate sessions on fatal errors

http://tlswg.github.io/tls13-spec/#alert-protocol says:

"Alert messages with a level of fatal result in the immediate termination of the connection. In this case, other connections corresponding to the session may continue, but the session identifier MUST be invalidated, preventing the failed session from being used to establish new connections."

However, this is not consistent with a stateless implementation of session tickets.
RFC5077 is a bit handwavy on this but implies that you shouldn't do this with tickets
(see also [SBR04] for discussion of this). I propose we remove this requirement


   [SBR04]     Shacham, H., Boneh, D., and E. Rescorla, "Client-side
              caching for TLS", Transactions on Information and System
              Security (TISSEC) , Volume 7, Issue 4, November 2004.

TLS mailing list
TLS <at> ietf.org