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
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 t
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
>
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 d
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 sm
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 a
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 en
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 cli
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 se
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 ea
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 E
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
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 do
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
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 requir
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
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
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 Ses
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
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 th
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
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/
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
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 l
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 i
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
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
> implementa
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 Certifi
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,
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
>>> di
30 matches
Mail list logo
