> On 27 Jan 2016, at 5:51 AM, Martin Thomson wrote:
>
> 4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon
> cipher suites.
>
> I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17
Quoting:
> My view: just because DH_anon is confused, doesn't mean we can't fix it
4472bis has a TBD regarding a missing "E" in the name of ECDHE_anon
cipher suites.
I raised an issue: https://github.com/tlswg/rfc4492bis/issues/17
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On 27 January 2016 at 14:11, David Benjamin wrote:
> Why do you say it's an optimization? They're exactly the same except the
> simplified one reduces to normal 0-RTT + mid-stream CertificateRequest (a
> combination that's possible with or without my restriction) and the other is
> a brand new han
On Tue, Jan 26, 2016 at 9:11 PM Eric Rescorla wrote:
> On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin
> wrote:
>
>> Instead of putting 0-RTT data in a ClientHello extension, the current
>> draft has the client send extra records in the first flight, right? (I see
>> an early_data extension, but
On Tue, Jan 26, 2016 at 9:11 PM Martin Thomson
wrote:
> On 27 January 2016 at 12:58, David Benjamin wrote:
> > If the server needs to send a CertificateRequest (i.e. the client
> > mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a
> > 0-RTT hit, have it reject 0-RTT altog
On 27 January 2016 at 13:11, Eric Rescorla wrote:
> Well, I think we're generally encouraging people to have to explicitly
> enable 0-RTT.
I think that the key point was that you would have to explicitly
enable 0-RTT AND that also meant a commitment not to choke on 0-RTT
data for at least as lon
On 27 January 2016 at 12:58, David Benjamin wrote:
> If the server needs to send a CertificateRequest (i.e. the client
> mispredicted the 0-RTT Certificate/CertificateVerify) but otherwise has a
> 0-RTT hit, have it reject 0-RTT altogether. The 0-RTT is already all but
> useless because the first
On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin
wrote:
> Instead of putting 0-RTT data in a ClientHello extension, the current
> draft has the client send extra records in the first flight, right? (I see
> an early_data extension, but it seems only be an indicator. There's also
> mention of requi
Instead of putting 0-RTT data in a ClientHello extension, the current draft
has the client send extra records in the first flight, right? (I see an
early_data extension, but it seems only be an indicator. There's also
mention of requiring trial decryption which only makes sense if it were
appended.
On Tue, Jan 26, 2016 at 8:28 PM Martin Thomson
wrote:
> This is in part why I created:
> https://github.com/tlswg/tls13-spec/pull/402
Ah, great. And indeed there is a paragraph I missed:
"""
At this point, the handshake is complete, and the client and server may
exchange application layer data.
This is in part why I created: https://github.com/tlswg/tls13-spec/pull/402
My understanding is that the server is able to send any data that does
not depend on client authentication at t=0.5 and any data that depends
on client authentication at either t=0.5 if it successfully consumes
the client
It's possible I'm reading the draft wrong, so this thread may be a very
short one.
(t here is in units of RTT, so t=0 is when the client sends ClientHello and
t=0.5 is when the server receives ClientHello and sends ServerHello, t=1 is
when the client receives ServerHello, etc.)
Looking at the Zer
Hi Stephen,
thanks for pointing to the review provided by Barry.
If you want, I can also issue a version -23 where I change the IANA
consideration section to avoid having the value zero unassigned
Ciao
Hannes
On 01/26/2016 11:21 PM, Stephen Farrell wrote:
>
> Hi all,
>
> I plan to send the a
On 01/25/2016 01:43 PM, Hubert Kario wrote:
> On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote:
>> On 01/22/2016 01:14 PM, Hubert Kario wrote:
>>> On Friday 22 January 2016 10:39:26 Andrey Jivsov wrote:
>>> If we don't do it for HS in TLS first, we'll never get rid of it in
>>> X.509 certs.
Hi all,
I plan to send the approval message for this tomorrow but
wanted to just check one thing first. In his IESG review [1]
Barry Leiba suggested reserving the value zero in the registry
created by section 8.2, which makes sense I think as otherwise
people will just be puzzled about what to do
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security Working Group of the
IETF.
Title : Transport Layer Security (TLS) Cached Information
Extension
Authors : Stefan Santesson
On Monday 25 January 2016 19:32:57 Andrey Jivsov wrote:
> On 01/25/2016 03:11 PM, Russ Housley wrote:
> > On Jan 25, 2016, at 2:43 PM, Hubert Kario wrote:
> >> On Monday 25 January 2016 10:29:18 Benjamin Kaduk wrote:
> >>> On 01/22/2016 01:14 PM, Hubert Kario wrote:
> On Friday 22 January 2016
17 matches
Mail list logo
