Hi all,
I am wondering why the certificate_request_context field found in the
CertificateRequest and in the Certificate message is so long. It is
supposed to be used to match a certificate request against incoming
certificate.
Does the field really need to be up to 256 bytes long? I think 8 bytes
On Fri, Oct 07, 2016 at 09:48:32AM +0200, Hannes Tschofenig wrote:
> Hi all,
>
> I am wondering why the certificate_request_context field found in the
> CertificateRequest and in the Certificate message is so long. It is
> supposed to be used to match a certificate request against incoming
> certi
On 7 October 2016 at 19:34, Ilari Liusvaara wrote:
> If application supports any sort of multiplexing (e.g. HTTP/2), one
> presumably wants the context to be non-opaque and identify the stream
> that caused the request + some parameters about the request (to avoid
> duplicating those in applicatio
Hi,
Recently I have started writing a TLS 1.3 implementation. While
working on it, I have noticed the following.
In section 4.4.3, the hash value used for building the HMAC is defined
as: Hash(Handshake Context + Certificate* + CertificateVerify*).
For ServerFinished, this corresponds to the sta
Hi Martin,
the problem is that with embedded implementations you need to be
prepared to receive this amount of data when the specification says so.
On 10/07/2016 10:59 AM, Martin Thomson wrote:
> On 7 October 2016 at 19:34, Ilari Liusvaara wrote:
>> If application supports any sort of multiplex
On 7 October 2016 at 20:45, Hannes Tschofenig wrote:
> the problem is that with embedded implementations you need to be
> prepared to receive this amount of data when the specification says so.
How are you managing 65k session tickets, extensions, cipher suite
lists, supported group lists, etc...
On Fri, Oct 07, 2016 at 06:41:35PM +0900, Kazuho Oku wrote:
> Hi,
>
> Recently I have started writing a TLS 1.3 implementation. While
> working on it, I have noticed the following.
>
> In section 4.4.3, the hash value used for building the HMAC is defined
> as: Hash(Handshake Context + Certificat
Hi Martin,
this may be an implementation specific issue but some of the parameters
I have to keep in memory while others I "only" have to parse. In some
cases the embedded implementation also has control over the number of
parameters being included in a message (which is useful for bandwidth
reaso
Changed milestone "Move ECC-based CS to Standards Track", set state to
active from review, accepting new milestone.
Changed milestone "DANE Record and DNSSEC Authentication Chain
Extension for TLS to IESG", set state to active from review, accepting
new milestone.
Changed milestone "DTLS1.3 to IE
I don't think it would be sensible to set an upper limit in this case
(those lead to regrets in my experience), however, recommending that
the value be kept as small as possible seems OK. It's probably
redundant advice though.
Since this is extremely transitory state, I sort-of assumed that it
wo
Hi,
Thank you very much for the clarification and the advise.
I had indeed forgotten to consider the client certificate and its verify
message.
iPhoneから送信
2016/10/07 19:14、Ilari Liusvaara のメッセージ:
>> On Fri, Oct 07, 2016 at 06:41:35PM +0900, Kazuho Oku wrote:
>> Hi,
>>
>> Recently I have sta
Hi Martin,
post-handshake authentication is indeed probably something that is less
likely to happen in the embedded environment and I will check whether
there are some use cases that require it.
If it isn't required then the best possible alternative at the moment is
for an embedded client implem
After the discussion on PR #615, I took another pass at this with some
help from the research community. Please see:
https://github.com/tlswg/tls13-spec/pull/672
Key changes in this PR:
1. I have merged the HMAC into the PreSharedKey message, where it is
now called "PSK Binder" to make very
Please see the following PR:
https://github.com/tlswg/tls13-spec/pull/673
This includes various changes to make exporters/resumption work better.
Basically:
1. Add a 0-RTT exporter and change the transcript for the regular exporter
so it
only includes the transcript up to ServerFinished. Th
On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> After the discussion on PR #615, I took another pass at this with some
> help from the research community. Please see:
>
>https://github.com/tlswg/tls13-spec/pull/672
>
>
> Key changes in this PR:
>
> 1. I have merged the HMAC
On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara
wrote:
> On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > After the discussion on PR #615, I took another pass at this with some
> > help from the research community. Please see:
> >
> >https://github.com/tlswg/tls13-spec/pull/
Hello,
Cloudflare's current (not definitive) plan for 0-RTT is essentially to
decide whether or not to answer to requests in the 0.5 flight on a
case-by-case basis. That obviously requires reading all of them and
caching the ones we don't want to answer.
To mitigate the obvious DoS concern we pla
On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
> On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara
> wrote:
>
> > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > > 4. I've taken a suggestion from David Benjamin to move the negotiation
> > > of the PSK key exchange
On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara
wrote:
> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > On Fri, Oct 07, 2016 at 08:01:43AM -0700, Eric Rescorla wrote:
> > > > 4.
On 10/07/2016 12:08 PM, Eric Rescorla wrote:
>
>
> On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara
> mailto:ilariliusva...@welho.com>> wrote:
>
> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara
> mailto:ilariliusva...@w
On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
wrote:
> On Fri, Sep 23, 2016 at 04:08:38PM -0700, Watson Ladd wrote:
>> Dear all,
>> We've got API guidance and application layer interactions on the TODO
>> list, and both of these are important and don't show up yet. I can't
>> credibly commit t
On Fri, Oct 7, 2016 at 1:39 PM, Benjamin Kaduk wrote:
> On 10/07/2016 12:08 PM, Eric Rescorla wrote:
>
>
>
> On Fri, Oct 7, 2016 at 10:03 AM, Ilari Liusvaara > wrote:
>
>> On Fri, Oct 07, 2016 at 09:35:40AM -0700, Eric Rescorla wrote:
>> > On Fri, Oct 7, 2016 at 8:26 AM, Ilari Liusvaara <
>> ila
I was assuming that there were two exporters:
Export() --> the same API as in 1.2 and computed as described here
Export0RTT -> A new API that computes the early_exporter.
-Ekr
On Fri, Oct 7, 2016 at 1:59 PM, Nick Harper wrote:
> Does the wording of this PR mean that the value from the exporte
That's my assumption as well.
On Fri, Oct 7, 2016 at 2:07 PM, Eric Rescorla wrote:
> I was assuming that there were two exporters:
>
> Export() --> the same API as in 1.2 and computed as described here
> Export0RTT -> A new API that computes the early_exporter.
>
>
> -Ekr
>
> On Fri, Oct 7, 2016
Good. I will try to clarify. PRs welcome
On Fri, Oct 7, 2016 at 2:37 PM, Nick Harper wrote:
> That's my assumption as well.
>
> On Fri, Oct 7, 2016 at 2:07 PM, Eric Rescorla wrote:
>
>> I was assuming that there were two exporters:
>>
>> Export() --> the same API as in 1.2 and computed as descr
On 10/07/2016 11:57 AM, Filippo Valsorda wrote:
> Hello,
>
> Cloudflare's current (not definitive) plan for 0-RTT is essentially to
> decide whether or not to answer to requests in the 0.5 flight on a
> case-by-case basis. That obviously requires reading all of them and
> caching the ones we don't
On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
> On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
> wrote:
> >
> > Also, it is very likely that 0-RTT would need its own read API, because
> > it is pretty unlikely that existing API could be safely retrofitted
> > or even purpose-buil
On Fri, Oct 7, 2016 at 3:00 PM, Ilari Liusvaara
wrote:
> On Fri, Oct 07, 2016 at 01:41:14PM -0700, Watson Ladd wrote:
> > On Fri, Sep 23, 2016 at 10:47 PM, Ilari Liusvaara
> > wrote:
> > >
> > > Also, it is very likely that 0-RTT would need its own read API, because
> > > it is pretty unlikely t
We were also expecting to want to bound how much traffic a server could be
compelled to skip over without making progress. It actually didn't occur to
me we could let the client know the bounds, rather than just making up a
conservative bound (there's only so much data you can get into an RTT) and
There has been a lot of discussion lately about post-handshake messages
that do not contain application data and how to handle them. This PR is an
attempt to make the story more explicit by adding a new post_handshake
extension to TLS 1.3.
Supporting all types of post-handshake messages can requir
30 matches
Mail list logo
