Re: [TLS] Does the ServerHello really need unencrypted extensions at all?

[Ilari Liusvaara]

On Sat, Jul 18, 2015 at 09:22:12PM -0400, Dave Garrett wrote:
> There's two issues (basically duplicates) for this topic, as well as an 
> inline TODO.
> https://github.com/tlswg/tls13-spec/issues/66
> https://github.com/tlswg/tls13-spec/issues/72
> https://tlswg.github.io/tls13-spec/#server-hello
> 
> The current expectation is to separate extensions into unencrypted and 
> encrypted, with:
> "The ServerHello MUST only include extensions which are required to establish 
> the cryptographic context."
> 
> The rest then go into the new EncryptedExtensions message.
> 
> Are there really any extensions that this applies to? What extension
> couldn't we get away with encrypting? As soon as ServerKeyShare is sent,
> the client should have enough information to decrypt the encrypted
> extensions message.

Going through extension list, I think the following need to go to
ServerHello (and aren't considered deprecated):

max_fragment_length (existing, IIRC, a single enumeration)
known_configuration (new in TLS 1.3, just an ACK flag)
pre_shared_key (new in TLS 1.3, PSK only, 1 octet string)
early_data(?) (new in TLS 1.3, just an ACK flag)

(Technically known_configuration and early_data could be pushed
further, but that would create annoying special cases).


Additionally, if the handshake shape is to be fixed by CH/SH,
the following need to go to SH, because these introduce or change
messages (post EE, so with variable shape, EE is possible):

client_certificate_url
status_request
user_mapping
client_authz
server_authz
status_request_v2
signed_certificate_timestamp


> Site note: ServerKeyShare could probably just be merged into
> ServerHello at this point:
> 
>struct {
>ProtocolVersion server_version;
>Random random;
>CipherSuite cipher_suite;
>select (DH) {
>case true:
>NamedGroup group;
>opaque key_exchange<1..2^16-1>;
>case false:
>struct {};
>};
>} ServerHello;
> 
> Even if an extension is desired to set up a cryptographic context,
> then ideally you'd want to set up a basic extension-less one _first_,
> send an encrypted extensions message containing that needed extension,
> then send a second encrypted extensions message using the new context
> using the extension. The goal is to encrypt all the things, per TLS WG
> charter, so I don't see a point in allowing unencrypted extensions in
> ServerHellos at all anymore.

Changing ServerHello has the problem of then having incompatible
message with the same message type (the only offender for this currently
is IIRC ServerConfig, which collides with TLS 1.2 ServerHelloDone).

Additionally, if you ever need a security fix extension (:vomit:), those
likely would have to go to ServerHello.


-Ilari

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

Re: [TLS] is it good using password for authentication only?

[Manuel Pegourie-Gonnard]

Hi,

On 6/19/15 13:03, Bingzheng Wu wrote:

I am wrong again. Adding master-secret is useless.

Now I think that asymmetric crypto must be used to prevent offline directory 
attack, which is the way PAKE works as.

I'm probably wrong since I only thought about it for a few minutes, but 
it seems to me that the PasswordVerify message would be encrypted with 
(keys derived from) the handshake master secret, which would prevent 
offline attacks.


What am I missing?


Sorry for disturbing.


Probably sorry too :)

Manuel.



--
From:武炳正(允中) 
Time:2015 Jun 19 (Fri) 16:19
To:武炳正(允中) , tls 
Subject:RE: [TLS] is it good using password for authentication only?

Maybe I realize the problem. The PasswordVerify message is susceptible to
offline dictionary attacks.

Dose it become resistant to the attack if we add some secret generated from
master-secret into the HASH?

   PasswordVerify = HASH(username, passward, handshake_message_hash,
master-secret, label)

This becomes involved with key-exchange, but it is not involved with any
specific key-exchange method.
It just need the key-exchange result.


Bingzheng

___
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] is it good using password for authentication only?

[Thijs van Dijk]

Hi Manuel,

On 19 July 2015 at 12:21, Manuel Pegourie-Gonnard  wrote:

> I'm probably wrong since I only thought about it for a few minutes, but it
> seems to me that the PasswordVerify message would be encrypted with (keys
> derived from) the handshake master secret, which would prevent offline
> attacks.
>
> What am I missing?


The key observation is the following: (I mentioned this off-list a few
weeks ago, but I guess I'll post it here as well for posterity.)

[T]he master secret will be derived from the client's and server's
> respective KeyShare messages, and will therefore be known at the time the
> server's PasswordVerify is sent. A malicious client could therefore perform
> half a handshake (just enough to get the server to give up its PV message),
> abort, and proceed with an offline attack in its own time.



I thought about switching the order in which server and client send their
> PV, but in much the same manner this won't protect clients from malicious
> servers.


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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Ilari Liusvaara]

On Sat, Jul 18, 2015 at 02:28:40PM -0400, Dave Garrett wrote:
> On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote:
> > This is not really what I was intending when I suggested the feature. I was
> > intending for their to be an indication, in the ClientHello, that the
> > server should not do any of the work that it would normally do to make the
> > session resumable.
> 
> Ok, I might as well write up the generic solution then:
> 
> https://github.com/tlswg/tls13-spec/compare/master...davegarrett:sessionrequest

Are the features besides "don't bother making resumable session, I won't
resume." needed?

E.g. For what would client hinting session lifetime be useful for?


-Ilari

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Eric Rescorla]

I'm not seeing a lot of value here. Remember that servers are not
required (and have never been required) to do session resumption, but
much of the overhead of doing it (having to have a database, session
ticket machinery) is associated with being willing to do session
resumption at all, so if a small fraction of clients would tell
you that they're not interested in resumption, it's not clear that
buys you much.

Are there any server operators who think this is a useful feature
and can explain why?

-Ekr


On Sun, Jul 19, 2015 at 2:50 PM, Ilari Liusvaara <
ilari.liusva...@elisanet.fi> wrote:

> On Sat, Jul 18, 2015 at 02:28:40PM -0400, Dave Garrett wrote:
> > On Saturday, July 18, 2015 01:06:33 am Brian Smith wrote:
> > > This is not really what I was intending when I suggested the feature.
> I was
> > > intending for their to be an indication, in the ClientHello, that the
> > > server should not do any of the work that it would normally do to make
> the
> > > session resumable.
> >
> > Ok, I might as well write up the generic solution then:
> >
> >
> https://github.com/tlswg/tls13-spec/compare/master...davegarrett:sessionrequest
>
> Are the features besides "don't bother making resumable session, I won't
> resume." needed?
>
> E.g. For what would client hinting session lifetime be useful for?
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Viktor Dukhovni]

On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote:

> I'm not seeing a lot of value here. Remember that servers are not
> required (and have never been required) to do session resumption, but
> much of the overhead of doing it (having to have a database, session
> ticket machinery) is associated with being willing to do session
> resumption at all, so if a small fraction of clients would tell
> you that they're not interested in resumption, it's not clear that
> buys you much.
> 
> Are there any server operators who think this is a useful feature
> and can explain why?

These days, I'm operating servers that only support session tickets
(no server-side cache).  If the client does not send the session
ticket extension, no session is cached.

So for servers that elect the same strategy, there's no need for
a separate means to signal the client's intentions.

-- 
Viktor.

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

Re: [TLS] is it good using password for authentication only?

[Mike Hamburg]

Also, it isn't too difficult to implement a PAKE.  But there isn't a 
(known?) way to do it without adding rounds, if you want to protect the 
username.  This is because the server needs the username before it can 
do anything with the password.  Unless it has 0-RTT information the 
client can't encrypt the username before receiving the server's 
ephemeral share.  So you need at least


ClientHello ->
<- ServerKeyshare
PakeStuff ->
<- PasswordVerify
PasswordVerify, Finished ->

(With other messages in there too of course, but these ones limit the 
round count with PAKE.)


-- Mike

On 7/19/2015 3:42 AM, Thijs van Dijk wrote:

Hi Manuel,

On 19 July 2015 at 12:21, Manuel Pegourie-Gonnard > wrote:


I'm probably wrong since I only thought about it for a few
minutes, but it seems to me that the PasswordVerify message would
be encrypted with (keys derived from) the handshake master secret,
which would prevent offline attacks.

What am I missing?


The key observation is the following: (I mentioned this off-list a few 
weeks ago, but I guess I'll post it here as well for posterity.)


[T]he master secret will be derived from the client's and server's
respective KeyShare messages, and will therefore be known at the
time the server's PasswordVerify is sent. A malicious client could
therefore perform half a handshake (just enough to get the server
to give up its PV message), abort, and proceed with an offline
attack in its own time. 


I thought about switching the order in which server and client
send their PV, but in much the same manner this won't protect
clients from malicious servers.


-Thijs


___
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] draft-shore-tls-dnssec-chain-extension-00

[Daniel Kahn Gillmor]

Thanks for this draft, i'm definitely interested in seeing it push
forward.

On Wed 2015-07-01 05:58:20 +0200, Viktor Dukhovni wrote:
> Instead, there would need to be in various cases:
>
> * A validated chain of CNAMEs (possibly synthesized via validated
>   DNAME RRs) leading from the client's requested SNI name to
>   a final TLSA base domain.  (0 or more CNAME/DNAME indirection
>   records and all the DNSKEY/DS/RRSIG records to validate
>   these).
>
> * A validated chain of CNAMES from _port._proto. to
>   an actual validated TLSA RRset (and ...).
>
> * The final TLSA RRset with all the requisite validation records.
>
> * Also a potential change in the client's notion of the reference
>   identifier to match in certificates, to the final TLSA base domain.

Complicating this further, there could be a chain to an SRV or MX
record, which then needs to chain to the TLSA, in think (possibly with
CNAMEs in the mix).  This is potentially a pretty long chain.  also: how
does a multi-tenanted server know what SRV or MX chain to include in the
chain?

--dkg

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

Re: [TLS] is it good using password for authentication only?

[Manuel Pegourie-Gonnard]

Hi Thijs,

On 7/19/15 12:42, Thijs van Dijk wrote:

On 19 July 2015 at 12:21, Manuel Pegourie-Gonnard  wrote:


I'm probably wrong since I only thought about it for a few minutes, but it
seems to me that the PasswordVerify message would be encrypted with (keys
derived from) the handshake master secret, which would prevent offline
attacks.

What am I missing?


The key observation is the following: (I mentioned this off-list a few
weeks ago, but I guess I'll post it here as well for posterity.)


[T]he master secret will be derived from the client's and server's
respective KeyShare messages, and will therefore be known at the time the
server's PasswordVerify is sent. A malicious client could therefore perform
half a handshake (just enough to get the server to give up its PV message),
abort, and proceed with an offline attack in its own time.


Indeed. Thanks!

(And sorry for the noise, as expected.)

Manuel.

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

Re: [TLS] A la carte handshake negotiation

[Manuel Pegourie-Gonnard]

Hi,

sorry for resurecting an old message on a fairly tangential point.

On 6/12/15 10:31, Ilari Liusvaara wrote:

AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for
both DHE (via ciphersuites) and ECDSA (via (possibly implicit default)
signature_algorithms).

(In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA)

Either we're not talking about the same thing, or we don't read RFC 5246 
in the same way. Section 7.4.2 (pages 47-48) says:


   -  The end entity certificate's public key (and associated
  restrictions) MUST be compatible with the selected key exchange
  algorithm.

  Key Exchange Alg.  Certificate Key Type
  [...]
  DHE_RSARSA public key; [...]

To me that clearly means that if the server selects a DHE_RSA 
ciphersuite, it MUST NOT use a certificate that contains an EC key, even 
if the client offered ECDSA in the signature_algorithm extension. 
However, in that case the certificate may be signed using ECDSA, which 
is not the same.



Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is
quite clear about interaction of signature algorithms in ciphersuites
and explicit signature negotiation (explicit negotiation always takes
percedence).

I'm afraid we both agree that TLS 1.2 is quite clear, but disagree about 
what it says, which is ironic :) My understanding is that, regarding the 
key in the server's certificate, there is indeed double negotiation, 
with a clear rule that the set of allowed choices is the intersection of 
what is allowed by the ciphersuite and what is allowed by the 
signature_algorithms extension.


   If the client has offered the "signature_algorithms" extension, the
   signature algorithm and hash algorithm MUST be a pair listed in that
   extension.  Note that there is a possibility for inconsistencies
   here.  For instance, the client might offer DHE_DSS key exchange but
   omit any DSA pairs 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.

To me, the "MUST check against" does not suggest "may still pick the 
DHE_DSS suite and use an RSA cert with it if signature_algorithms 
contains acceptable RSA pairs".


Regarding other signatures in the certificate chain, only 
signature_algorithms apply, so there is no "double negotiation" indeed.



Of course, I wouldn't be surprised if there was fair bit of software
that got those rules wrong...

Regardless of whether your interpretation or mine is correct, I'm pretty 
sure various implementations will do things in different ways here. 
Anyway, a large proportion of servers deployments only have one cert, in 
which case the RFC says "it [the server] SHOULD attempt to validate that 
it [the certificate] meets these criteria", which may be interpreted as 
an indication that the server may try to send its only certificate 
anyway and let the client decide how to deal with it.


Manuel.

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

Re: [TLS] A la carte handshake negotiation

[Eric Rescorla]

On Sun, Jul 19, 2015 at 8:53 PM, Manuel Pegourie-Gonnard 
wrote:

> Hi,
>
> sorry for resurecting an old message on a fairly tangential point.
>
> On 6/12/15 10:31, Ilari Liusvaara wrote:
>
>> AFAICT, In TLS 1.2, DHE+ECDSA is legal, if client signals support for
>> both DHE (via ciphersuites) and ECDSA (via (possibly implicit default)
>> signature_algorithms).
>>
>> (In TLS 1.1 and earlier, there is seemingly no way to use DHE+ECDSA)
>>
>>  Either we're not talking about the same thing, or we don't read RFC 5246
> in the same way. Section 7.4.2 (pages 47-48) says:
>
>-  The end entity certificate's public key (and associated
>   restrictions) MUST be compatible with the selected key exchange
>   algorithm.
>
>   Key Exchange Alg.  Certificate Key Type
>   [...]
>   DHE_RSARSA public key; [...]
>
> To me that clearly means that if the server selects a DHE_RSA ciphersuite,
> it MUST NOT use a certificate that contains an EC key, even if the client
> offered ECDSA in the signature_algorithm extension. However, in that case
> the certificate may be signed using ECDSA, which is not the same.
>
>  Also, there is no "double negotiation" in TLS 1.2 either. TLS 1.2 is
>> quite clear about interaction of signature algorithms in ciphersuites
>> and explicit signature negotiation (explicit negotiation always takes
>> percedence).
>>
>>  I'm afraid we both agree that TLS 1.2 is quite clear, but disagree about
> what it says, which is ironic :) My understanding is that, regarding the
> key in the server's certificate, there is indeed double negotiation, with a
> clear rule that the set of allowed choices is the intersection of what is
> allowed by the ciphersuite and what is allowed by the signature_algorithms
> extension.
>
>If the client has offered the "signature_algorithms" extension, the
>signature algorithm and hash algorithm MUST be a pair listed in that
>extension.  Note that there is a possibility for inconsistencies
>here.  For instance, the client might offer DHE_DSS key exchange but
>omit any DSA pairs 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.
>
> To me, the "MUST check against" does not suggest "may still pick the
> DHE_DSS suite and use an RSA cert with it if signature_algorithms contains
> acceptable RSA pairs".
>
> Regarding other signatures in the certificate chain, only
> signature_algorithms apply, so there is no "double negotiation" indeed.


This is how I understand the situation as well. I am sad to hear that we
didn't
manage to make the document clear on this point.

-Ekr


>
>  Of course, I wouldn't be surprised if there was fair bit of software
>> that got those rules wrong...
>>
>>  Regardless of whether your interpretation or mine is correct, I'm pretty
> sure various implementations will do things in different ways here. Anyway,
> a large proportion of servers deployments only have one cert, in which case
> the RFC says "it [the server] SHOULD attempt to validate that it [the
> certificate] meets these criteria", which may be interpreted as an
> indication that the server may try to send its only certificate anyway and
> let the client decide how to deal with it.
>
> Manuel.
>
>
> ___
> 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] draft-shore-tls-dnssec-chain-extension-00

[Viktor Dukhovni]

On Sun, Jul 19, 2015 at 08:18:18PM +0200, Daniel Kahn Gillmor wrote:

> On Wed 2015-07-01 05:58:20 +0200, Viktor Dukhovni wrote:
> > Instead, there would need to be in various cases:
> >
> > * A validated chain of CNAMEs (possibly synthesized via validated
> >   DNAME RRs) leading from the client's requested SNI name to
> >   a final TLSA base domain.  (0 or more CNAME/DNAME indirection
> >   records and all the DNSKEY/DS/RRSIG records to validate
> >   these).
> >
> > * A validated chain of CNAMES from _port._proto. to
> >   an actual validated TLSA RRset (and ...).
> >
> > * The final TLSA RRset with all the requisite validation records.
> >
> > * Also a potential change in the client's notion of the reference
> >   identifier to match in certificates, to the final TLSA base domain.
> 
> Complicating this further, there could be a chain to an SRV or MX
> record, which then needs to chain to the TLSA, in think (possibly with
> CNAMEs in the mix).  This is potentially a pretty long chain.  also: how
> does a multi-tenanted server know what SRV or MX chain to include in the
> chain?

My reading of the draft is that it is primary aimed at making DANE
practical for HTTPS,  where last-mile considerations on the client
end are a significant part of the adoption barrier.

For HTTP, MX and SRV records are out of scope.  Clients that depend
on DNS to the extent of determining the server identity based on
MX or SRV records, already need DNSSEC to avoid MiTM issues, and
at least in the case of SMTP and XMPP are expected to handle DANE
without stapled TLSA RRsets (and associated RRSIG/DNSKEY/DS chains).

-- 
Viktor.

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Brian Smith]

On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni 
wrote:

> On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote:
>
> > I'm not seeing a lot of value here. Remember that servers are not
> > required (and have never been required) to do session resumption, but
> > much of the overhead of doing it (having to have a database, session
> > ticket machinery) is associated with being willing to do session
> > resumption at all, so if a small fraction of clients would tell
> > you that they're not interested in resumption, it's not clear that
> > buys you much.
> >
> > Are there any server operators who think this is a useful feature
> > and can explain why?
>
> These days, I'm operating servers that only support session tickets
> (no server-side cache).  If the client does not send the session
> ticket extension, no session is cached.
>
> So for servers that elect the same strategy, there's no need for
> a separate means to signal the client's intentions.
>

First, I think that there should be only one way to do resumption in TLS
1.3 anyway. All I'm asking for is that the client have some way of
indicating whether or not it supports resumption. Viktor's method seems
fine with me.

Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft
actually contains a regression here. It seems like it is no longer possible
for the server to indicate how long a PSK should be held by the client to
resume a session, and it seems like it is no longer possible for the server
to indicate that it doesn't support resumption.

I don't know that the lifetime hint is valuable, but being able to reduce
attack surface by being disabling resumption for a session seems clearly
useful. See https://www.secure-resumption.com/, CVE-2014-1490 in
Firefox/NSS, and CVE-2015-1791 in OpenSSL, which show that it can be useful
to avoid resumption in many cases.

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

Re: [TLS] A la carte handshake negotiation

[Dave Garrett]

Since the last time I posted it here, I've made some changes. Everything is 
rebased on top of what is now PR #201 (it's not really severable from that).

https://github.com/davegarrett/tls13-spec/compare/alertsandcerts...davegarrett:alacarte

Now that resumption is PSK-based, some of the language might need tweaking for 
that, but I not everything is sorted out for PSK-based resumption yet. (there's 
TODOs in the draft; e.g., doesn't yet say what cipher suites are to be used for 
resumption)

Other than that, it's at a state that (with PR #201) I could submit a PR if we 
can agree that this is the general path forward. The highlights of this 
proposal, for those who didn't follow the previous (long) discussions on the 
topic:

* All DH, DHE, ECDH, RSA, and DSS cipher suites are deprecated. (some could 
still be offered for backwards compatibility, just like before)
* The only compatible cipher suites would be those with a handshake portion of 
ECDHE_ECDSA, ECDHE_PSK, PSK, or ECDHE_anon. (there is an exception in there for 
completely new stuff, which will essentially be amending this anyway)
* All ECDHE_ECDSA suites can negotiate ECHDE/DHE & ECDSA/DSA/RSA via the 
existing extensions. (no new extensions need to be defined to do this)
* Likewise, ECDHE_PSK and ECDHE_anon can negotiate ECHDE/DHE via the existing 
extension.
* A new standards track RFC to promote ECDHE suites from informational is 
needed, but that was already true.
* In addition to reducing combinatorial nonsense with the suites, it results in 
deprecation of existing DHE suites in favor or DHE done via ECDHE labeled 
suites only with strong groups.

This is the general result of previous discussions. The alternate route that 
came up was just to ditch the concept of cipher suites entirely and add a new 
extension to negotiate the AEAD cipher/hash to use with the existing 
extensions. There's nothing that would preclude moving to that more extreme 
route if this were to be accepted first, as ECDHE/DHE negotiation via the 
extension would be needed for that too. I think the WG is more in favor of the 
route proposed in this changeset at the moment, though.


Dave

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Eric Rescorla]

On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith  wrote:

> On Sun, Jul 19, 2015 at 1:16 PM, Viktor Dukhovni 
> wrote:
>
>> On Sun, Jul 19, 2015 at 02:56:22PM +0200, Eric Rescorla wrote:
>>
>> > I'm not seeing a lot of value here. Remember that servers are not
>> > required (and have never been required) to do session resumption, but
>> > much of the overhead of doing it (having to have a database, session
>> > ticket machinery) is associated with being willing to do session
>> > resumption at all, so if a small fraction of clients would tell
>> > you that they're not interested in resumption, it's not clear that
>> > buys you much.
>> >
>> > Are there any server operators who think this is a useful feature
>> > and can explain why?
>>
>> These days, I'm operating servers that only support session tickets
>> (no server-side cache).  If the client does not send the session
>> ticket extension, no session is cached.
>>
>> So for servers that elect the same strategy, there's no need for
>> a separate means to signal the client's intentions.
>>
>
> First, I think that there should be only one way to do resumption in TLS
> 1.3 anyway. All I'm asking for is that the client have some way of
> indicating whether or not it supports resumption. Viktor's method seems
> fine with me.
>
> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft
> actually contains a regression here. It seems like it is no longer possible
> for the server to indicate how long a PSK should be held by the client to
> resume a session,
>

Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint
value.

http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12


and it seems like it is no longer possible for the server to indicate that
> it doesn't support resumption.
>

Well, it can't indicate it, but if it doesn't supply a session ticket,
there's no way for
the client to do it.

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Brian Smith]

Eric Rescorla  wrote:

> On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith 
> wrote:
>
>> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft
>> actually contains a regression here. It seems like it is no longer possible
>> for the server to indicate how long a PSK should be held by the client to
>> resume a session,
>>
>
> Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint
> value.
>
> http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12
>
> and it seems like it is no longer possible for the server to indicate that
>> it doesn't support resumption.
>>
>
> Well, it can't indicate it, but if it doesn't supply a session ticket,
> there's no way for
> the client to do it.
>

Great. I was misunderstanding. Here's the part that is not is still not
clear to me: Is the SessionTicket extension still to be used or not? It
seems not, AFAICT. If the SessionTicket extension were to be used, then
everything would work perfectly as Viktor suggested in his message: the
absense of the SessionTicket extension in the ClientHello would be the way
that a client can indicate that it doesn't want the session to be cached.

It seems weird that the server can supply a lifetime hint but the client
can't, especially in cases like WebRTC where there is no functional
difference between the two. But, that's a smaller issue than the lack of an
indication that resumption machinery isn't wanted at all.

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Eric Rescorla]

On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith  wrote:

> Eric Rescorla  wrote:
>
>> On Sun, Jul 19, 2015 at 10:17 PM, Brian Smith 
>> wrote:
>>
>>> Maybe I'm misunderstanding, but it looks like the current TLS 1.3 draft
>>> actually contains a regression here. It seems like it is no longer possible
>>> for the server to indicate how long a PSK should be held by the client to
>>> resume a session,
>>>
>>
>> Not unless I've made a mistake. NewSessionTicket contains a lifetime_hint
>> value.
>>
>> http://tlswg.github.io/tls13-spec/#rfc.section.6.3.12
>>
>> and it seems like it is no longer possible for the server to indicate
>>> that it doesn't support resumption.
>>>
>>
>> Well, it can't indicate it, but if it doesn't supply a session ticket,
>> there's no way for
>> the client to do it.
>>
>
> Great. I was misunderstanding. Here's the part that is not is still not
> clear to me: Is the SessionTicket extension still to be used or not? It
> seems not, AFAICT. If the SessionTicket extension were to be used, then
> everything would work perfectly as Viktor suggested in his message: the
> absense of the SessionTicket extension in the ClientHello would be the way
> that a client can indicate that it doesn't want the session to be cached.
>

No, it's not used.


It seems weird that the server can supply a lifetime hint but the client
> can't, especially in cases like WebRTC where there is no functional
> difference between the two. But, that's a smaller issue than the lack of an
> indication that resumption machinery isn't wanted at all.
>

I don't think it's *that* odd, since tickets have at least two fundamental
asymmetries:

- The client needs to actually keep state and the server does not
(that being the point of tickets)
- The client (because they speak first) gets to offer the ticket for
resumption and the server can accept it or reject it.

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Dave Garrett]

On Sunday, July 19, 2015 04:49:10 pm Eric Rescorla wrote:
> On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith  wrote:
> > Great. I was misunderstanding. Here's the part that is not is still not
> > clear to me: Is the SessionTicket extension still to be used or not? It
> > seems not, AFAICT. If the SessionTicket extension were to be used, then
> > everything would work perfectly as Viktor suggested in his message: the
> > absense of the SessionTicket extension in the ClientHello would be the way
> > that a client can indicate that it doesn't want the session to be cached.
> 
> No, it's not used.

This draft spec explicitly obsoletes RFC 5077. (listed up top)
https://tools.ietf.org/html/rfc5077#section-3.2


Dave

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Viktor Dukhovni]

On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote:

> Here's the part that is not is still not
> clear to me: Is the SessionTicket extension still to be used or not?

While we now have

   https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4

   In TLS 1.2 and below, this functionality was provided by "session
   resumption" and "session tickets" [RFC5077].  Both mechanisms are
   obsoleted in TLS 1.3.

at the same time we also have:

   https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11

   After the server has received the client Finished message, it MAY
   send a NewSessionTicket message.  This message MUST be sent before
   the server sends any application data traffic, and is encrypted under
   the application traffic key.  This message creates a pre-shared key
   (PSK) binding between the resumption master secret and the ticket
   label.  The client MAY use this PSK for future handshakes by
   including it in the pre_shared_key extension in its ClientHello
   (Section 6.3.1.5.4) and supplying a suitable PSK cipher suite.

 struct {
 uint32 ticket_lifetime_hint;
 opaque ticket<0..2^16-1>;
 } NewSessionTicket;

   ticket_lifetime_hint
  Indicates the lifetime in seconds as a 32-bit unsigned integer in
  network byte order.  A value of zero is reserved to indicate that
  the lifetime of the ticket is unspecified.

   ticket
  The value of the ticket to be used as the PSK identifier.

and

   https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.1.5.4

   The pre_shared_key extension is used to indicate the identity of the
   pre-shared key to be used with a given handshake in association with
   a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for background).

 opaque psk_identity<0..2^16-1>;

 struct {
   select (Role) {
 case client:
   psk_identity identities<0..2^16-1>;

 case server:
   psk_identity identity;

 } PreSharedKeyExtension;

   identifier
  An opaque label for the pre-shared key.

So indeed it is no longer possible for the client to signal the
ability/desire to resume sessions, and servers will generate session
tickets absent any indication that the client intends to use them.

This does not impose a space penalty on the server, but some CPU
and bandwidth may be wasted on clients that don't or can't resume.

> It seems not, AFAICT. If the SessionTicket extension were to be used, then
> everything would work perfectly as Viktor suggested in his message: the
> absense of the SessionTicket extension in the ClientHello would be the way
> that a client can indicate that it doesn't want the session to be cached.

In the current 1.3 draft, there is indeed no client signal.

> It seems weird that the server can supply a lifetime hint but the client
> can't, especially in cases like WebRTC where there is no functional
> difference between the two. But, that's a smaller issue than the lack of
> an indication that resumption machinery isn't wanted at all.

The client lifetime is not that useful with session tickets anyway,
whether the client caches at all, could be, but it is not clear
that the resulting "inefficiency" needs to be fixed.  The fix would
be for the client to send an empty extension of some sort to signal
its desire to elicit a session ticket.

-- 
Viktor.

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

Re: [TLS] draft-shore-tls-dnssec-chain-extension-00

[Melinda Shore]

On 7/19/15 11:49 AM, Viktor Dukhovni wrote:
> My reading of the draft is that it is primary aimed at making DANE
> practical for HTTPS,  where last-mile considerations on the client
> end are a significant part of the adoption barrier.
> 
> For HTTP, MX and SRV records are out of scope.  Clients that depend
> on DNS to the extent of determining the server identity based on
> MX or SRV records, already need DNSSEC to avoid MiTM issues, and
> at least in the case of SMTP and XMPP are expected to handle DANE
> without stapled TLSA RRsets (and associated RRSIG/DNSKEY/DS chains).

Yup, exactly.  Thanks.

Melinda


-- 
Melinda Shore
No Mountain Software
melinda.sh...@nomountain.net

"Software longa, hardware brevis."

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Viktor Dukhovni]

On Sun, Jul 19, 2015 at 04:58:02PM -0400, Dave Garrett wrote:

> This draft spec explicitly obsoletes RFC 5077. (listed up top)
> https://tools.ietf.org/html/rfc5077#section-3.2

However, part of RFC 5077 remains applicable:

   https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11

   The ticket itself is an opaque label.  It MAY either be a
   database lookup key or a self-encrypted and self-authenticated
   value.  Section 4 of [RFC5077] describes a recommended ticket
   construction mechanism.

-- 
Viktor.

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Eric Rescorla]

On Sun, Jul 19, 2015 at 11:03 PM, Viktor Dukhovni 
wrote:

> On Sun, Jul 19, 2015 at 04:40:15PM -0400, Brian Smith wrote:
>
> > Here's the part that is not is still not
> > clear to me: Is the SessionTicket extension still to be used or not?
>
> While we now have
>
>https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.2.4
>
>In TLS 1.2 and below, this functionality was provided by "session
>resumption" and "session tickets" [RFC5077].  Both mechanisms are
>obsoleted in TLS 1.3.
>
> at the same time we also have:
>
>https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.11
>
>After the server has received the client Finished message, it MAY
>send a NewSessionTicket message.  This message MUST be sent before
>the server sends any application data traffic, and is encrypted
> under
>the application traffic key.  This message creates a pre-shared key
>(PSK) binding between the resumption master secret and the ticket
>label.  The client MAY use this PSK for future handshakes by
>including it in the pre_shared_key extension in its ClientHello
>(Section 6.3.1.5.4) and supplying a suitable PSK cipher suite.
>
>  struct {
>  uint32 ticket_lifetime_hint;
>  opaque ticket<0..2^16-1>;
>  } NewSessionTicket;
>
>ticket_lifetime_hint
>   Indicates the lifetime in seconds as a 32-bit unsigned integer in
>   network byte order.  A value of zero is reserved to indicate that
>   the lifetime of the ticket is unspecified.
>
>ticket
>   The value of the ticket to be used as the PSK identifier.
>
> and
>
>https://tools.ietf.org/html/draft-ietf-tls-tls13-07#section-6.3.1.5.4
>
>The pre_shared_key extension is used to indicate the identity of the
>pre-shared key to be used with a given handshake in association with
>a PSK or (EC)DHE-PSK cipher suite (see [RFC4279] for background).
>
>  opaque psk_identity<0..2^16-1>;
>
>  struct {
>select (Role) {
>  case client:
>psk_identity identities<0..2^16-1>;
>
>  case server:
>psk_identity identity;
>
>  } PreSharedKeyExtension;
>
>identifier
>   An opaque label for the pre-shared key.
>
> So indeed it is no longer possible for the client to signal the
> ability/desire to resume sessions, and servers will generate session
> tickets absent any indication that the client intends to use them.
>
> This does not impose a space penalty on the server, but some CPU
> and bandwidth may be wasted on clients that don't or can't resume.


Yes.

So my question is whether there are an appreciably large number of servers
each of which have an appreciably large fraction of *both* caching and
non-caching clients to make an optimization like this worthwhile (servers
which only have non-caching or only caching clients can just send
or not send a ticket as appropriate)

-Ekr


>
> > It seems not, AFAICT. If the SessionTicket extension were to be used,
> then
> > everything would work perfectly as Viktor suggested in his message: the
> > absense of the SessionTicket extension in the ClientHello would be the
> way
> > that a client can indicate that it doesn't want the session to be cached.
>
> In the current 1.3 draft, there is indeed no client signal.
>
> > It seems weird that the server can supply a lifetime hint but the client
> > can't, especially in cases like WebRTC where there is no functional
> > difference between the two. But, that's a smaller issue than the lack of
> > an indication that resumption machinery isn't wanted at all.
>
> The client lifetime is not that useful with session tickets anyway,
> whether the client caches at all, could be, but it is not clear
> that the resulting "inefficiency" needs to be fixed.  The fix would
> be for the client to send an empty extension of some sort to signal
> its desire to elicit a session ticket.
>
> --
> Viktor.
>
> ___
> 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] TLS 1.3 - method to request uncached shared secrets

[Dave Garrett]

On Sunday, July 19, 2015 05:03:56 pm Viktor Dukhovni wrote:
> In the current 1.3 draft, there is indeed no client signal.
[...]
> The fix would be for the client to send an empty extension of some
> sort to signal its desire to elicit a session ticket.

Why is the SessionTicket TLS Extension being deprecated at all? Sure, obsolete 
the RFC, but include the same extension in the TLS 1.3 spec with the same 
semantics for requesting a ticket from the server (0-length to request). This 
could be backwards compatible easily enough.


Dave

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Brian Smith]

Eric Rescorla  wrote:

> On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith 
> wrote:
>
>> It seems weird that the server can supply a lifetime hint but the client
>> can't, especially in cases like WebRTC where there is no functional
>> difference between the two. But, that's a smaller issue than the lack of an
>> indication that resumption machinery isn't wanted at all.
>>
>
> I don't think it's *that* odd, since tickets have at least two fundamental
> asymmetries:
>
> - The client needs to actually keep state and the server does not
> (that being the point of tickets)
>

It depends on how the server implements tickets. The server could implement
tickets the same way that it implements session ID-based resumption. That's
not a good idea, but I don't think the spec should prohibit that type of
implementation either since it unenforceable. Thus, because of that
possibility, it is valuable to have the client be able to say "don't cache
the session" and/or limit the session's lifetime, so the client can help
direct the level of forward secrecy for the session. Right now, only the
server has a say in how long a session will be forward-secret.

Note also that the NewSessionTicket extension precedes any application
data, so without a way to prevent an unwanted NewSessionTicket message from
being sent, the client has to waste effort and time to consume the
NewSessionTicket before it can do anything useful.

Anyway, I don't understand why you keep directing your question to server
vendors. The people that would be interested in such a feature are client
software vendors, for client software that wants to control the level of
forward secrecy for a session.

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Viktor Dukhovni]

On Sun, Jul 19, 2015 at 11:10:42PM +0200, Eric Rescorla wrote:

> > So indeed it is no longer possible for the client to signal the
> > ability/desire to resume sessions, and servers will generate session
> > tickets absent any indication that the client intends to use them.
> >
> > This does not impose a space penalty on the server, but some CPU
> > and bandwidth may be wasted on clients that don't or can't resume.
> 
> Yes.
> 
> So my question is whether there are an appreciably large number of servers
> each of which have an appreciably large fraction of *both* caching and
> non-caching clients to make an optimization like this worthwhile (servers
> which only have non-caching or only caching clients can just send
> or not send a ticket as appropriate)

Such a mixture of clients is not at all uncommon with SMTP.  Not
all MTAs implement client-side TLS session caches (no such cache
in Exim or Sendmail).  However, sending a session ticket either
way is not a major burden for SMTP servers.  It would however be
nice to not waste resources doing so, if an appropriate extension
(say the existing one) were used to signal client support.

This is not an absolutely compelling argument in favour of client
signalling, more of an observation that it could be useful.

-- 
Viktor.

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Viktor Dukhovni]

On Sun, Jul 19, 2015 at 05:28:27PM -0400, Brian Smith wrote:

> Thus, because of that
> possibility, it is valuable to have the client be able to say "don't cache
> the session" and/or limit the session's lifetime, so the client can help
> direct the level of forward secrecy for the session. Right now, only the
> server has a say in how long a session will be forward-secret.

I think this is too much complexity, for too little gain.  Servers
will limit the lifetime of local session storage rather severely
to avoid running out of space.

> Note also that the NewSessionTicket extension precedes any application
> data, so without a way to prevent an unwanted NewSessionTicket message from
> being sent, the client has to waste effort and time to consume the
> NewSessionTicket before it can do anything useful.

This is typically much smaller than the server certificate chain,
so the cost saving is marginal.

> Anyway, I don't understand why you keep directing your question to server
> vendors. The people that would be interested in such a feature are client
> software vendors, for client software that wants to control the level of
> forward secrecy for a session.

I don't think the client would gain much if any control by signalling
a lifetime hint.  With actual session tickets, the key rotation
lifecycle determines the effective forward-secrecy exposure (to
server state compromise before a key is retired) of the ticket,
and no client hint can influence that in any way.

So I agree with Eric that the issue is fundamentally a server-side
issue, modulo the fact that the CPU and bandwidth cost of processing
the unwanted ticket is borne on both sides.

-- 
Viktor.

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Dave Garrett]

On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote:
> It depends on how the server implements tickets. The server could implement
> tickets the same way that it implements session ID-based resumption. That's
> not a good idea, but I don't think the spec should prohibit that type of
> implementation either since it unenforceable. Thus, because of that
> possibility, it is valuable to have the client be able to say "don't cache
> the session" and/or limit the session's lifetime, so the client can help
> direct the level of forward secrecy for the session. Right now, only the
> server has a say in how long a session will be forward-secret.
> 
> Note also that the NewSessionTicket extension precedes any application
> data, so without a way to prevent an unwanted NewSessionTicket message from
> being sent, the client has to waste effort and time to consume the
> NewSessionTicket before it can do anything useful.

If the general ticket lifetime request route is not needed, here's the simplest 
route: just don't drop the Session Ticket extension.

https://github.com/tlswg/tls13-spec/compare/master...davegarrett:recycleticketextension

This keeps it with the same semantics for requesting a ticket, thus allowing 
TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2 servers with 
no additional effort. TLS 1.3 sessions would be resumed using the new PSK-based 
method and TLS 1.2 sessions would be resumed using the old session ticket 
extension.

Should I submit this as a PR? It seems like the obvious route if all we want is 
to just keep the ability for a client to not request a ticket. No need to write 
a new extension at all.


Dave

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

[TLS] Another way to reduce signature computational cost

[Bingzheng Wu]

Hi all,

In TLS 1.3 draft-07, server provides a ServerConfiguration message containing a 
long-term DH share.
If used on future connections:

(1) server reduces the computational cost for cipher suites where signatures 
are slower than key agreement;
(2) server omits both the Certificate or CertificateVerify message;
(3) and client encrypts zero-rtt data.


Here I'd like to give another way to reach (1), to reduce server's computational
cost for CertificateVerify message for RSA type certificate.

In normal way, the CertificateVerify is computed as:
CA ==> CA2 ==> srv_cert_RSA --> session
where "==>" means reusing signature, and "-->" means signature for each session 
which is computation sensitive.

Maybe the server can generate a temparary ECC certificate, so the 
CertificateVerify is computed as:
CA ==> CA2 ==> srv_cert_RSA ==> tmp_cert_ECC --> session
and the structure of CertificateVerify message becomes:

  struct {
   ECParam tmp_cert_public;
   timetmp_cert_not_before;
   timetmp_cert_not_after;
   digitally-signed struct {
  opaque handshake_hash[hash_length];
   }
  } CertificateVerify;


Compared to ServerConfiguration, this tmp_cert_ECC has some advantages:

* The tmp_cert only modify the CertificateVerify message.
  While the ServerConfiguration brings MS and SS concepts.

* The tmp_cert need not to be global.
  If there are multiple machines or processes behind one service,
  they must synchronize the key share for ServerConfiguration.
  In practice the key share is always configured in server's configure
  file and need rotated periodically manually, like the ticket key in Nginx.
  While the tmp_cert can be generated randomly and independently.

* The tmp_cert's lifetime could be short.
  It could be re-new after used for only 100 times, or 10 minutes.

* The tmp_cert works even for the first connection.


So could we use this tmp_cert to replace ServerConfiguration's "reducing 
computation" function?

The "omitting Certificate message" could be reached by cached-info extension.
Then the ServerConfiguration can be used for zero-rtt data exclusively.


Thanks
Bingzheng

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Eric Rescorla]

On Mon, Jul 20, 2015 at 12:12 AM, Dave Garrett 
wrote:

> On Sunday, July 19, 2015 05:28:27 pm Brian Smith wrote:
> > It depends on how the server implements tickets. The server could
> implement
> > tickets the same way that it implements session ID-based resumption.
> That's
> > not a good idea, but I don't think the spec should prohibit that type of
> > implementation either since it unenforceable. Thus, because of that
> > possibility, it is valuable to have the client be able to say "don't
> cache
> > the session" and/or limit the session's lifetime, so the client can help
> > direct the level of forward secrecy for the session. Right now, only the
> > server has a say in how long a session will be forward-secret.
> >
> > Note also that the NewSessionTicket extension precedes any application
> > data, so without a way to prevent an unwanted NewSessionTicket message
> from
> > being sent, the client has to waste effort and time to consume the
> > NewSessionTicket before it can do anything useful.
>
> If the general ticket lifetime request route is not needed, here's the
> simplest route: just don't drop the Session Ticket extension.
>
>
> https://github.com/tlswg/tls13-spec/compare/master...davegarrett:recycleticketextension
>
> This keeps it with the same semantics for requesting a ticket, thus
> allowing TLS 1.3 clients to request tickets from both TLS 1.3+ and TLS 1.2
> servers with no additional effort. TLS 1.3 sessions would be resumed using
> the new PSK-based method and TLS 1.2 sessions would be resumed using the
> old session ticket extension.
>
> Should I submit this as a PR? It seems like the obvious route if all we
> want is to just keep the ability for a client to not request a ticket. No
> need to write a new extension at all.


As I said initially, I'm having trouble seeing why this is particularly
useful.

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

Re: [TLS] TLS 1.3 - method to request uncached shared secrets

[Eric Rescorla]

On Sun, Jul 19, 2015 at 11:28 PM, Brian Smith  wrote:

> Eric Rescorla  wrote:
>
>> On Sun, Jul 19, 2015 at 10:40 PM, Brian Smith 
>> wrote:
>>
>>> It seems weird that the server can supply a lifetime hint but the client
>>> can't, especially in cases like WebRTC where there is no functional
>>> difference between the two. But, that's a smaller issue than the lack of an
>>> indication that resumption machinery isn't wanted at all.
>>>
>>
>> I don't think it's *that* odd, since tickets have at least two fundamental
>> asymmetries:
>>
>> - The client needs to actually keep state and the server does not
>> (that being the point of tickets)
>>
>
> It depends on how the server implements tickets. The server could
> implement tickets the same way that it implements session ID-based
> resumption. That's not a good idea, but I don't think the spec should
> prohibit that type of implementation either since it unenforceable.
>

I don't think that the current spec does so.



> Thus, because of that possibility, it is valuable to have the client be
> able to say "don't cache the session" and/or limit the session's lifetime,
> so the client can help direct the level of forward secrecy for the session.
> Right now, only the server has a say in how long a session will be
> forward-secret.
>
> Note also that the NewSessionTicket extension precedes any application
> data, so without a way to prevent an unwanted NewSessionTicket message from
> being sent, the client has to waste effort and time to consume the
> NewSessionTicket before it can do anything useful.
>
> Anyway, I don't understand why you keep directing your question to server
> vendors. The people that would be interested in such a feature are client
> software vendors, for client software that wants to control the level of
> forward secrecy for a session.
>

I think perhaps you have misunderstood the forward secrecy properties of the
current draft. Unlike TLS 1.2 and previous, the current draft has a separate
resumption master secret which is independently derived from the master
secret used for the connection keys in the original connection. This means
that if you don't resume the connection, you have forward secrecy for the
original connection regardless of whether the server stores the session in
the session cache or sends the client a ticket.

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