Re: [TLS] SHA-3 in SignatureScheme

[Joseph Salowey]

While there seems to be some support for adding SHA-3 to TLS, we're not
seeing enough support to add it as part of TLS 1.3.  Individual drafts that
specify ciphers suites can always be separately considered though.

Cheers,

J

On Fri, Sep 9, 2016 at 4:30 AM, Martin Thomson 
wrote:

> On 9 September 2016 at 20:02, Gilles Van Assche 
> wrote:
> > My point was technically how to best use FIPS 202 in RSA PSS, and we (as
> > Keccak team) would be more than happy to help in that area.
>
> And I'm more than happy to have the work happen, but I think that we
> can do things in stages.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Finished stuffing

[Benjamin Kaduk]

I made a few notes on the pull request.  Generally, I support the
change, but I get the sense that it may aid the cryptographic properties
if we keep the resumption_context and do not overload the resumption_psk
as much.

I have a slight (i.e., unjustified) preference for doing
ClientHello-with-block-of-zeros rather than prefix-of-ClientHello.  (Is
there a reason to require this extension to be the last one with
block-of-zeros?  Clearly there is for prefix-of-ClientHello.)

-Ben

On 09/06/2016 11:49 PM, Joseph Salowey wrote:
> Hi Folks,
>
> The chairs want to make sure this gets some proper review.   Please
> respond with comments by Friday so we can make some progress on this
> issue. 
>
> Thanks,
>
> J
>
> On Tue, Sep 6, 2016 at 11:57 AM, David Benjamin  > wrote:
>
> I think this is a good idea. It's kind of weird, but it avoids
> giving the early Finished such a strange relationship with the
> handshake transcript. Also a fan of doing away with multiple PSK
> identities if we don't need it.
>
> As a bonus, this removes the need to route a "phase" parameter
> into the traffic key calculation since we'll never derive more
> than one epoch off of the same traffic secret. Combine that with
> the two-ladder KeyUpdate and we no longer need any concatenation
> or other label-munging at all. Simply use labels "key" and "iv"
> and the record-layer just exposes a single UseTrafficSecret
> function which saves the traffic secret (for KeyUpdate), derives
> the traffic keys, and engages the new AEAD in one swoop without
> mucking about with phases, traffic directions, whether we are
> client or server, etc.
>
> David
>
> On Thu, Sep 1, 2016 at 6:19 PM Eric Rescorla  > wrote:
>
> I should also mention that this makes the implementation a
> fair bit simpler because:
>
> 1. You can make all the decisions on the server side
> immediately upon receiving the ClientHello
> without waiting for Finished.
> 2. You don't need to derive early handshake traffic keys.
>
> From an implementor's perspective, this outweighs the messing
> around with the ClientHello buffer.
> -Ekr
>
>
> On Thu, Sep 1, 2016 at 3:04 PM, Eric Rescorla  > wrote:
>
> Folks,
>
> I have just posted a WIP PR for what I'm calling "Finished
> Stuffing"
>
>   https://github.com/tlswg/tls13-spec/pull/615
> 
> 
>
> I would welcome comments on this direction and whether I
> am missing
> anything important.
>
>
> OVERVIEW
> This PR follows on a bunch of discussions we've had about
> the redundancy
> of Finished and resumption_ctx. This PR makes the
> following changes:
>
> - Replace the 0-RTT Finished with an extension you send in the
>   ClientHello *whenever* you do PSK.
> - Get rid of resumption context (because it is now replaced by
>   the ClientHello.hello_finished.
>
>
> RATIONALE
> The reasoning for this change is:
>
> - With ordinary PSK you don't get any assurance that the
> other side
>   knows the PSK.
>
> - With 0-RTT you get some (subject to the usual anti-replay
>   guarantees) via the Finished message.
>
> - If we were to include the 0-RTT Finished message in the
> handshake
>   transcript, then we wouldn't need the resumption context
> because
>   the transcript would transitively include the PSK via
> the Finished.
>
> So the natural thing to do would be to always send 0-RTT
> Finished
> but unfortunately:
>
> 1. You can't just send the 0-RTT Finished whenever you do
> PSK because
>that causes potential compat problems with mixed
> 1.3/1.2 networks
>(the same ones we have with 0-RTT, but at least that's
> opt-in).
>
> 2. You also can't send the 0-RTT Finished with PSK because
> you can
>currently offer multiple PSK identities.
>
> The on-list discussion has suggested we could relax
> condition #2 and
> only have one identity. And we can fix condition #1 by
> stuffing the
> Finished in an extension (with some hacks to make this
> easier). 

[TLS] closing KeyUpdate

[Sean Turner]

The discussion about KeyUpdate-related changes has trailed off so it is time to 
begin to bring the discussion to a close.  It appears that there as if there is 
support to land https://github.com/tlswg/tls13-spec/pull/61.  But, there’s 
still some discussion about how to add both P3 and P4 [0].  In the interest of 
making progress, we're instructing the editor to land PR#61 now.

Keith had argued for a restriction that wouldn't introduce any wire changes: 
i.e., forbid implementations from sending an update_not_requested KeyUpdate 
unless it is triggered by an update_requested KeyUpdate.  Ilari has pointed out 
a limitation with this approach, but the question is: does the WG favor the 
restriction proposed by Keith? Please let the WG know by next Wednesday (9/14) 
so that we can come closure on this topic.

Thanks,

J

[0] Where Keith suggested:

P3 = A side can learn that P1 has been read by the other side.

P4 = Neither side can cause the other to accrue an unbounded deferred write 
obligation; in fact the maximum accruable deferred write obligation is one 
KeyUpdate.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Pre_shared_key Extension Question

[Salz, Rich]

We don't do cert rollover, we shouldn't do PSK rollver.


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

Re: [TLS] Suspicious behaviour of TLS server implementations

[Martin Rex]

My personal take on your questions:


Andreas Walz wrote:
> 
> (1) Several server implementations seem to ignore the list of proposed
> compression methods in a ClientHello and simply select null compression
> even if that has not been in the ClientHello's list.

Sounds like reasonable behaviour (improving interop) which does not cause
any security issues.

>
> The specification is rather clear that null compression MUST be part of
> the list.  However, I'm not aware of any clear statement about what a
> compliant server should do in case it receives a ClientHello without
> null compression. My best guess would have been that in such cases the
> server should abort the handshake (at least if it does not support
> whatever the client proposed).

The requirement is about the Client.  The Server behaviour is un(der)specifed.
The server choosing null compression anyway and continuing looks pretty
reasonable to me (least amount of code, so the safest to implement).

Aborting by the server would be OK with the specification, but not
necessarily reasonable.  Consider that there was a time when compression
within TLS was available and widely used.  A server that wanted and would
use TLS compression when offered would behave sort-of unrational when
complaining about an absence of a compression method it does not intend
to use (in presence of the compression method it wants to use).

The actual problem is the design flaw in TLS that availability of 
null compression is not implied, but rather given a seperate codepoint,
and the server choosing null compression and continuing even when it
is not explicitly asserted by the client, is a server silently making up
for that design flaw in the TLS spec.


> 
> (2) In a ClientHello several server implementations don't ignore data
> following the extension list. That is, they somehow seem to ignore the
> length field of the extension list and simply consider everything
> following the list of compression methods as extensions.  Aside from this
> certainly being a deviation from the specification, I was wondering
> whether a server should silently ignore data following the extension
> list (e.g. for the sake of upward compatibility) or (as one could infer
> from RFC5246, p. 42) send e.g. a "decode_error" alert.

Up to TLSv1.2, TLS extensions were purely optional, so an implementation
that unconditionally ignores everything following compression methods is
at least fully conforming to SSLv3, TLSv1.0 and TLSv1.1.

For an TLS implementation that parses TLS extensions, the behaviour of
what to do about trailing garbage is a different matter.  Personally
I prefer aborting in case of garbage trailing TLS extensions.

When I looked at OpenSSL's implemenation of the extensions parser a few
years ago, I noticed that it was ignoring (I believe up to 3) trailing bytes.
(the shortest possible TLS extension is 4 bytes).


>
> (3) If a ClientHello contains multiple extensions of the same type,
> several server implementations proceed with the handshake (even if they
> parse these specific extensions). The specification again is clear that
> "there MUST NOT be more than one extension of the same type".
> However, what should a server do in case there are? Again, my guess
> would be that it should abort the handshake. Should this also be the
> case for extensions that a server simply ignores (as it e.g. doesn't
> know them)?

What the server does in presence of multiple TLS extensions of the same type
is implementation defined.  I think it would be extremely reasonable for a
server to perform a simple plausibility check on decode whether it is decoding
the same TLS extension more than once, and then abort with a decode_error
alert, in order to have ambiguities caught early.
Recognizing duplicate TLS extensions that the server does not
support/implement does not (yet) create ambiguities (for that server)
and requires more complex code, so I would not implement that check.


-Martin

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

Re: [TLS] Pre_shared_key Extension Question

[Hannes Tschofenig]

Hi Benjamin,

regarding the use case you describe below: at least for us at ARM this 
is not the way how we plan to use PSK. We use a key distribution 
protocol (namely OMA LWM2M) to provision the PSK identity and the PSK 
secret used with TLS.


So, from that point of view there is no need for a PSK rollover as you 
describe below.


Ciao
Hannes

On 08/18/2016 05:47 PM, Benjamin Kaduk wrote:

On 08/18/2016 10:29 AM, Eric Rescorla wrote:



On Thu, Aug 18, 2016 at 8:18 AM, Benjamin Kaduk > wrote:

On 08/17/2016 05:17 PM, Eric Rescorla wrote:

It would be a fairly significant simplification to say you could
only have one PSK, because then we could easily require the
client to prove knowledge of the key, for instance by stuffing a
MAC at the end of the ClientHello as we discussed in Berlin.

So:
Is there any demand for multiple identities? I do not believe
there is any in the Web context. If not, we should remove this
feature.



Then at PSK rollover time, clients are expected to fall back to a
new TLS connection using the other PSK?


I'm not sure I follow. Can you say more?



With caveat that I don't deploy PSK-based systems and this is before my
morning coffee ... suppose I have a related group of IoT devices that
use TLS+PSK to communicate.  But, I don't want the long-term
cryptographic secret (the PSK) to be permanent and unchanging, since
that's not best practices and leaves me in a tough spot if it ever
leaks.  So, I generate a new PSK every three months, provide a device on
the network that lets the devices retrieve the new one, and everyone is
supposed to expire the old one a month after the new one is available.
My PSK identities could then be something like "2016Q2" (or something
more complicated; it doesn't really matter), but since the devices are
autonomous and not synchronized, I can't have a "flag day" transition
from using the 2016Q1 to 2016Q2 key.  At some point, a device will try
to use the 2016Q2 key as a client against a server device that only has
the 2016Q1 key, and the handshake fails.  In the rollover scenario I
describe, the client can then try a new handshake with the 2016Q1 key
instead of the 2016Q2 key, which should succeed.

Given the benefits of only allowing one PSK identity from the client, I
am fine with requiring the second hanshake in this (contrived?)
scenario; I just wanted to mention it so that we know what we're getting
into.

-Ben


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

Re: [TLS] Pre_shared_key Extension Question

[Hannes Tschofenig]

Hi Ekr,

thanks for the response.

The psk_identity_hint in RFC 4279 was sent from the server to the client 
and was a mechanism that was believed to be needed by the 3GPP in their 
bootstrapping architecture, which in the end was never widely used (as 
far as I know). So, not necessarily a super important features, as it 
seems.


As mentioned in my other mail regarding sending the ticket together with 
the long-term PSK identity could be addressed better by clarifying the 
server is intending to keep the ticket cached for the time indicated in 
ticket_lifetime (rather than saying the opposite which may lead 
implementers to care less).


Hence, I would mind if you delete the following two sentences in Section 
4.5.1 "New Session Ticket Message":


"
It MAY delete the ticket earlier based on local policy. A server MAY 
treat a ticket as valid for a shorter period of time than what is stated 
in the ticket_lifetime.

"

Ciao
Hannes


On 08/18/2016 12:17 AM, Eric Rescorla wrote:

The intention here was to compensate for not having psk_identity_hint.
However, it also allows you to do resumption of PSK-established sessions.

It would be a fairly significant simplification to say you could only
have one PSK, because then we could easily require the client to prove
knowledge of the key, for instance by stuffing a MAC at the end of the
ClientHello as we discussed in Berlin.

So:
Is there any demand for multiple identities? I do not believe there is
any in the Web context. If not, we should remove this feature.

-Ekr


On Thu, Aug 11, 2016 at 1:39 AM, Hannes Tschofenig
> wrote:

Hi all,

the currently defined “pre_shared_key” extension allows clients to send
a list of the identities. I was wondering in what use cases this is
useful and what policy guides the server to pick the most appropriate
psk identity. I couldn't find any discussion in the document about this
aspect.

Ciao
Hannes


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





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

Re: [TLS] PR#625: Change alert requirements

[Hannes Tschofenig]

Hi Ekr,

I read through the text and I think it is an improvement.

I only had one question that is only slightly related to your edits 
because it came up in the interop testing with the Mint implementation.


"
Servers requiring this extension SHOULD respond to a ClientHello
lacking a "server_name" extension by terminating the connection
with a "missing_extension" alert.
"

I personally would find it more useful to have an alert saying 
"missing_server_name_extension" instead of just returning 
"missing_extension" for a number of different extensions since this 
gives the client no chance to fix the problem without human intervention.


Ciao
Hannes

On 09/05/2016 08:02 PM, Eric Rescorla wrote:

PR: https://github.com/tlswg/tls13-spec/pull/625

Currently the TLS spec requires implementations to send alerts under various
fatal conditions. However, many stacks actually don't send alerts but
instead
just terminate the connection. Several people have argued that we should
relax
the requirement.

At the September 2015 interim there was consensus to instead encourage
sending alerts and require that if you send an alert, you send a
specific one.
I've finally gotten around to producing a PR that does this (link
above). This
PR:

- Harmonizes all the language around alert sending (though perhaps I missed
  a couple of places)
- Tries to make which alerts to send clearer in the alert descriptions
to avoid
  having to specify individually how to handle every decision.
- Relaxes the requirement as listed above.

Note that these are to some extent orthogonal changes; even if we decide to
continue mandating sending alerts, that should be listed in one location not
scattered around the spec.

I know that there wasn't universal consensus on relaxing the requirement to
send, so I'll await WG discussion and the chairs decision on how to
handle this PR.

-Ekr



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



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

Re: [TLS] Short Authentication Strings for TLS

[Hannes Tschofenig]

Hi Christian,

could you provide a bit more background why you are working on such a 
solution?


Ciao
Hannes


On 08/18/2016 07:47 PM, Christian Huitema wrote:

Daniel Kaiser and I are working on a “pairing” specification in the
context of DNS SD. Short Authentication Strings are one of the preferred
methods for verifying pairings. I would like to use TLS as much as
possible in the pairing protocol. EKR pointed me to the expired draft by
Ian Miers, Matthew Green and him:
https://tools.ietf.org/html/draft-miers-tls-sas-00. I am interested in
reviving that draft.



The draft implements a classic “coin flipping” protocol into TLS, using
a “commit before disclose” logic to prevent Nessie from hiding as an
MITM between Alice and Bob. From my superficial reading, this looks
fine. I could use a reference to
http://people.csail.mit.edu/shaih/pubs/hm96.pdf, both to explain why the
attack by Halevi and Micali does not apply to this particular construct,
and also to provide a 20 years old reference to similar algorithms,
which may be useful in this day and age.



One nit, though. If Nessie has infinite computing resource, she can
build a catalog of multiple random values that all hash to the same
string, and then use that catalog to work around the commitment
protocol. The scheme in the draft prevents that attack by using a hash
keyed with the master secret, which defeats catalog attacks, and also by
limiting the length of the nonce to be below the length of the hash,
which in theory prevents collision attacks. Explaining that would be neat.



As I said, I am interested in reviving that draft, and adapting it to
TLS 1.3. Does someone else share the feeling?



-- Christian Huitema







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



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

[TLS] Suspicious behaviour of TLS server implementations

[Andreas Walz]

Dear all,

we are working on an approach/framework for testing TLS implementations 
(currently only servers, but clients are planned for the future as well). While 
running our tests against a bunch of different TLS (server) implementations, we 
found several types of suspicious behaviour (see below). As the TLS 
specification left me with doubts on what the correct behaviour should be, I'd 
like to raise this questions here (please let me know if this is not the 
appropriate place or this has been answered before).

(1) Several server implementations seem to ignore the list of proposed 
compression methods in a ClientHello and simply select null compression even if 
that has not been in the ClientHello's list. The specification is rather clear 
that null compression MUST be part of the list. However, I'm not aware of any 
clear statement about what a compliant server should do in case it receives a 
ClientHello without null compression. My best guess would have been that in 
such cases the server should abort the handshake (at least if it does not 
support whatever the client proposed).

(2) In a ClientHello several server implementations don't ignore data following 
the extension list. That is, they somehow seem to ignore the length field of 
the extension list and simply consider everything following the list of 
compression methods as extensions. Aside from this certainly being a deviation 
from the specification, I was wondering whether a server should silently ignore 
data following the extension list (e.g. for the sake of upward compatibility) 
or (as one could infer from RFC5246, p. 42) send e.g. a "decode_error" alert.

(3) If a ClientHello contains multiple extensions of the same type, several 
server implementations proceed with the handshake (even if they parse these 
specific extensions). The specification again is clear that "there MUST NOT be 
more than one extension of the same type". However, what should a server do in 
case there are? Again, my guess would be that it should abort the handshake. 
Should this also be the case for extensions that a server simply ignores (as it 
e.g. doesn't know them)?

Thank you very much.

Cheers,
Andi


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

Re: [TLS] Version negotiation, take two

[Hannes Tschofenig]

I like this approach.

On 09/08/2016 06:04 PM, David Benjamin wrote:

Hi folks,

I’d like to revisit the question of version negotiation.

EKR wrote up some text for moving version negotiation to an extension:
https://github.com/tlswg/tls13-spec/pull/632

I would like us to adopt this proposal.

In Berlin, this really got framed as a pragmatic question: the current
version negotiation has a lot of intolerance and so let’s work around
that. So, understandably, this seemed like a “let’s adopt a hack
forever” proposal. I think that framing is wrong. The intolerance
situation is serious, but I think there’s also a strong argument that
the current scheme isn’t very good.

The current scheme is very simple. The client advertises a maximum
version and the server selects based on that. This is the only piece of
TLS negotiation which works this way. Elsewhere (extensions, cipher
suites, signature algorithms), one side offers a list and the other side
picks out of it. I think it’s clear now that strategy is more robust:
every time we’ve bumped version numbers, we’ve had intolerance problems
and this time is no exception (see below). By contrast, we regularly
introduce new cipher suites, extensions, etc., and while we do see the
occasional failure, they are much rarer and typically within the level
of breakage that clients can tolerate and deal with by reaching out to
affected servers. Moreover, lists lend themselves to future-proofing via
draft-davidben-tls-grease-00 in a way the current scheme does not.

An additional benefit is lists make it much easier to roll out
prototype/draft versions. Currently, we are using a hack where the
client offers {3, 4} but also includes a draft version number in an
extension. This does work, but requires servers process that extension
in perpetuity or at least until all draft version clients go away.  With
a list, it’s trivial to offer a draft version by just including it. This
is the strategy HTTP/2 used (via ALPN) and it worked well.

Despite all of the above, it probably wouldn’t be worth fixing version
negotiation in 1.3 except for intolerance. Unfortunately, this fourth
time, it’s the same story as before. A probe of Alexa top million sites
with BoringSSL’s TLS 1.3 code (the Go version), shows 1.63% of
TLS-capable hosts reject a TLS 1.3 ClientHello. Note these are top sites
and traffic is top-heavy, so we can expect much higher usage-weighted
numbers. Qualys SSL Pulse reports 3.6%:
https://blog.qualys.com/ssllabs/2016/08/02/tls-version-intolerance-in-ssl-pulse

(Ignore the drop in the graph. We’ve long fixed the ClientHello
record-layer at {3, 1}. TLS 1.3 only codified existing practice here.)
If instead we use a TLS 1.3 ClientHello with version TLS 1.2, the
breakage drops to 0.017%. (Some of this is an NSS signature algorithms
bug, fixed last year, which we hope to clear by deploying RSA-PSS in
browsers early. The rest appears to be noise from transient errors which
crop up in large tests.)

These numbers are *far* too high for clients to accept as damage, which
means that they (at least browsers) will be forced to do fallback. This
represents a security risk (cf. POODLE) as well as hides serious interop
problems. The situation is even worse for non-browser clients, which may
be unable to deploy at all (Ubuntu 12.04, despite shipping an OpenSSL
release with TLS 1.2, had to disable it on the client.
https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1256576/comments/4 )

The major arguments against this change seem to be:

1. It’s inelegant to have two mechanisms.
2. We should fix broken servers

The first is true, but as with other changes, EKR’s PR replaces the 1.2
mechanism with one for 1.3, so we’ll just have one going forward. The
second would be nice, but as a practical matter, I spend a lot of time
trying to get those servers fixed and it doesn’t work very well here.
Better is simply to move to a situation where once those servers upgrade
they will be correctly behaving forever (instead of just handling 1.3
correctly and breaking with 1.4). This change does that.

Thanks,

David


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



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

Re: [TLS] Finished stuffing

[Hannes Tschofenig]

Hi Ekr,

I have no problems with the suggested change but I would like to note 
that we are losing one feature with this change.


Limiting the client to only send a single psk_identity prevents the 
client from sending a ticket together with the long-term PSK identity in 
the same message. This was previously possible and useful since the 
server could delete state (based on local policy) prior to the indicated 
ticket lifetime.


Ciao
Hannes

On 09/02/2016 12:04 AM, Eric Rescorla wrote:

Folks,

I have just posted a WIP PR for what I'm calling "Finished Stuffing"

  https://github.com/tlswg/tls13-spec/pull/615

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


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

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


RATIONALE
The reasoning for this change is:

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

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

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

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

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

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

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


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

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


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

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

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

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

  opaque FinishedValue<0..255>;

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

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

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

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

Comments welcome.
-Ekr



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



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

[TLS] Zero-RTT Data & PSK

[Hannes Tschofenig]

Hi all,

the current spec says:

---
2.3. Zero-RTT Data

When resuming via a PSK with an appropriate ticket (i.e., one with the 
“allow_early_data” flag), clients can also send data on their first 
flight (“early data”).

---

I am wondering why I cannot use Zero-RTT with just PSK-based 
authentication (without a prior ticket change).


Ciao
Hannes

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

Re: [TLS] SHA-3 in SignatureScheme

[Martin Thomson]

On 9 September 2016 at 20:02, Gilles Van Assche  wrote:
> My point was technically how to best use FIPS 202 in RSA PSS, and we (as
> Keccak team) would be more than happy to help in that area.

And I'm more than happy to have the work happen, but I think that we
can do things in stages.

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

Re: [TLS] SHA-3 in SignatureScheme

[Gilles Van Assche]

I don't mind if this is done in a separate spec.

My point was technically how to best use FIPS 202 in RSA PSS, and we (as
Keccak team) would be more than happy to help in that area.

Kind regards,
Gilles


On 09/09/16 06:20, Martin Thomson wrote:
> On 7 September 2016 at 18:24, Ilari Liusvaara  
> wrote:
>> Therefore I think that this work should be pursued in a separate spec,
>> not in TLS 1.3 core.
> I think that Ilari has it here.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

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

Re: [TLS] Finished stuffing

[Martin Thomson]

On 9 September 2016 at 18:22, Ilari Liusvaara  wrote:
> Basically, one can't make a distinction between static ("non-resumption)
> and dynamic ("resumption") PSKs here. Because such distinction would
> run into security problems with some other features.


You mean that there is no inherent property that forces separation
between sessions that use resumption vs. those that use a regular PSK.
Though the former is bound to an ALPN value and cipher suite (and
maybe some other things, like server identity) and cannot be used
unless those values remain fixed, whereas the latter is not.

We're imposing those restrictions artificially for convenience for the
most part, though 0-RTT can be used to justify the two values I
mentioned.  Given that you need the same coupling of PSK to
ALPN+cipher suite if you intend to use a non-resumption PSK for 0-RTT,
maybe instead we can fix your "problem" by identifying what needs to
be bound and forcing them to remain bound for all PSKs.  (I use scare
quotes here because I'm not convinced that it is a problem worth
worrying about.)

That limits choice, but it would remove any divergence between the two.

Note that we already couple the hash function to a PSK for very good
reasons.  So you can't use both ChaCha and AES-256 with the same PSK.

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

Re: [TLS] Finished stuffing

[Ilari Liusvaara]

On Thu, Sep 08, 2016 at 09:59:22PM -0400, Hugo Krawczyk wrote:
> On Thu, Sep 8, 2016 at 5:29 AM, Ilari Liusvaara 
> wrote:
> 
> > On Wed, Sep 07, 2016 at 07:43:53PM -0400, Hugo Krawczyk wrote:
> >
> > - The hash has output length at most input length (true for all SHA-2
> > variants)
> >
> 
> Just curious: Can you explain the need for this property? Note that if a
> key to HMAC is  ​larger than the (compression) function output size then
> this key is first hashed into a full output hence preserving CR.

Simply me not bothering to figure out what the heck HMAC does if this
isn't true (or if it is even well-defined in all cases).

> - HKDF-extract salt length is constant (in current draft, always hash_olen)
> > - HKDF-expand PRK length is constant (in current draft, always hash_olen)
> > - The HKDF-expand output output length is at least hash output length
> >   (in current draft, hash_olen except in key expansions).
> >
> 
> These are a lot of restrictions that no one has spelled out as conditions
> on the KDF and they do not follow from the natural properties of KDFs.
> Collision resistance is never needed as far as I can tell for generation of
> keys or to compute PRF and/or MAC values (e.g., for the original
> functionality of Finished that is essentially a MAC/PRF on the transcript).
> The reason we find ourselves considering the CR properties of HKDF is that
> we are using it to derive *strings* that serve as binders/digests of past
> transcripts. Luckily, HKDF with the right hash functions can provide that
> functionality but it is not a native KDF functionality.

So I presume some more text for Security Considerations...
 
> I do not mean this as an academic discussion (although we could have that
> too) but as a warning for future (if not present) misuse and an obstacle in
> replacing HKDF in the future.
> I would be much happier if we had a clear distinction between PRF/MAC
> ​computations, KDF computations and digest computations., even if we
> currently used HKDF for all these functions.

Unfortunately there are things like exporter outputs, that need to be
both "secret" (i.e. "keys") and "nonces" (i.e. "binders"). At least if
application wants so... Dropping either would cause MAJOR security
problems.

I think those and the dynamically provisioned PSKs are the only ones
that have that property of being both key and binder.

> > It is a bit more problematic than that:
> >
> > The hello_finished / "PSK Creation Binder" derives from the PSK key.
> >
> > Deriving separate value in context of dynamic PSK provisioning does not
> > work properly as "static" PSKs lack this value, and if one then tries to
> > use such key with combined authentication, you got an attack[1].
> >
> 
> ​I could not follow this argument.
 
Basically, one can't make a distinction between static ("non-resumption)
and dynamic ("resumption") PSKs here. Because such distinction would
run into security problems with some other features.



-Ilari

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