Reviving this thread, I also think it would also be a good idea if 1.3 did
not stripping zeros from Z. Having this logic is rather dubious w.r.t.
treating secret data in constant-time. And as Bill Cox mentioned elsewhere
in this thread, this odd behavior has caused interoperability issues in the
pa
If the WG agrees with this change, I've put together a PR here:
https://github.com/tlswg/tls13-spec/pull/462
On Tue, May 17, 2016 at 4:14 PM David Benjamin
wrote:
> Reviving this thread, I also think it would also be a good idea if 1.3 did
> not stripping zeros from Z. Having th
In case folks hoped we could bump the ClientHello version without those
dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much
exists. (Maybe we should just give up on ClientHello.version and use an
extension? Extensions have rusted less.)
I picked a large list of top sites and
be accepting plain RSA for a long while.)
David
>
> On Wed, Jun 1, 2016 at 3:29 PM, David Benjamin
> wrote:
>
>> In case folks hoped we could bump the ClientHello version without those
>> dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance very much
>>
On Thu, Jun 2, 2016 at 6:40 AM Hubert Kario wrote:
> On Wednesday 01 June 2016 22:29:06 David Benjamin wrote:
> > In case folks hoped we could bump the ClientHello version without
> > those dreaded browser fallbacks, I have bad news. :-( 1.3 intolerance
> > very much exi
On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote:
> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
> > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
> > > wrote:>
> > > On Wed, 2016-06-01 at 15:43 -0700, Eric Rescorla wrote:
> > >> 2% is actually pretty good, but I agree that we're g
On Thu, Jun 2, 2016 at 10:59 AM Viktor Dukhovni
wrote:
>
> > On Jun 2, 2016, at 10:49 AM, David Benjamin
> wrote:
> >
> > I'm not sure I follow. The specification certainly spells out how
> version negotiation is supposed to work. That hasn't st
On Thu, Jun 2, 2016 at 11:07 AM David Benjamin
wrote:
> On Thu, Jun 2, 2016 at 6:43 AM Hubert Kario wrote:
>
>> On Thursday 02 June 2016 11:39:20 Yoav Nir wrote:
>> > > On 2 Jun 2016, at 10:31 AM, Nikos Mavrogiannopoulos
>> > > wrote:>
>> > &g
On Thu, Jun 2, 2016 at 11:20 AM Hubert Kario wrote:
> > > Speaking of version number, does the text say that a server _MUST_
> > > accept any version higher than the one that is specified in the RFC,
> > > but reply with 0x03,0x04 in case it doesn't support any future
> > > version of the protoco
I think I could be convinced in either direction right now.
It is definitely ugly and more of a nuisance to implement. The alternative
is a fallback and then painfully driving it out later. We've done that
before and we have FALLBACK_SCSV and the server_random trick now.
At the same time, I am ra
I'm not sure I follow why the additional "generation" machinery is
necessary.
What do we gain from having the server to tell us to discard a ticket
beyond what the ticket lifetime already gives? This doesn't seem an
effective way to discard key material since, unlike the ticket lifetime, we
need a
ks
> it's that valuable. I *do* think it's important that we make sure that
> analysis supports multiple tickets pointing to the same underlying RMS.
>
> -Ekr
>
> On Sat, Jun 4, 2016 at 10:06 AM, David Benjamin
> wrote:
>
>> I'm not sure I follow why
On Tue, Jun 7, 2016 at 5:06 PM Yoav Nir wrote:
>
> > On 7 Jun 2016, at 8:33 PM, Hubert Kario wrote:
> >
> > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote:
> >> I’m not sure this helps.
> >>
> >> I’ve never installed a server that is version intolerant. TLS stacks
> >> from OpenSSL, Microsoft,
On Tue, Jun 21, 2016 at 1:54 PM Ilari Liusvaara
wrote:
> On Tue, Jun 21, 2016 at 10:07:17AM -0700, Ryan Hamilton wrote:
> > On Mon, Jun 20, 2016 at 6:15 PM, Martin Thomson <
> martin.thom...@gmail.com>
> > wrote:
> >
> > > David Benjamin wrote our sectio
On Tue, Jun 21, 2016 at 8:45 PM Martin Thomson
wrote:
> On 22 June 2016 at 10:30, Bill Frantz wrote:
> > Well, it seems like a browser could try TLS 1.3 without 0-RTT first.
> >
> > If it connects with 1.3 non-0-RTT, then it could mark the host as not
> > supporting 0-RTT for a day or so and aft
t; > state machine.
> >
> > David Benjamin rather flippantly described a solution to this problem:
> > XOR the ticket age value with something that is either derived from
> > the old session keys or was included in the NewSessionTicket message.
> >
> > I propo
On Thu, Jun 23, 2016 at 6:35 AM David Benjamin
wrote:
> On Thu, Jun 23, 2016 at 6:35 AM Ilari Liusvaara
> wrote:
>
>> On Thu, Jun 23, 2016 at 01:37:14PM +1000, Martin Thomson wrote:
>> > When implementing 0-RTT, an in particular the ticket_age extension, we
>>
On Tue, Jun 28, 2016 at 1:02 PM Hubert Kario wrote:
> On Thursday 23 June 2016 18:53:39 Ilari Liusvaara wrote:
> > On Thu, Jun 23, 2016 at 07:26:37AM -0700, Watson Ladd wrote:
> > > On Tue, Jun 21, 2016 at 8:58 PM, Martin Thomson
> > > wrote:
> > > > On 22 June 2016 at 12:01, Watson Ladd wrote:
On Wed, Jun 1, 2016 at 6:57 PM Eric Rescorla wrote:
> On Wed, Jun 1, 2016 at 3:53 PM, David Benjamin
> wrote:
>
>> On Wed, Jun 1, 2016 at 6:43 PM Eric Rescorla wrote:
>>
>>> 2% is actually pretty good, but I agree that we're going to need
>>> fal
On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir wrote:
>
> > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara
> wrote:
> >
> > On Mon, Jul 04, 2016 at 03:46:00PM +0300, Yoav Nir wrote:
> >> Hi
> >>
> >> Based on an email exchange with Nikos Mavrogiannopoulos, I’ve submitted
> a PR.
> >>
> >> https://github.co
On Wed, Jul 6, 2016 at 2:11 PM Yoav Nir wrote:
> Hi, Joe
>
> > On 6 Jul 2016, at 8:39 PM, Joseph Salowey wrote:
> >
> > We are the unenviable position of calling consensus between three
> choices [0]:
> >
> > - Option 1 - use the same key for both handshake and applications
> messages.
> > - Opt
On Wed, Jul 6, 2016 at 5:39 PM Eric Rescorla wrote:
> On Wed, Jul 6, 2016 at 5:24 PM, Dave Garrett
> wrote:
>
>> On Wednesday, July 06, 2016 06:19:29 pm David Benjamin wrote:
>> > I'm also curious which post-handshake messages are the problem. If we
>>
On Thu, Jul 7, 2016 at 7:29 PM Watson Ladd wrote:
> I don't think we can use name constraints here. Yes, they are opt-in
> and clients can indicate support, but it may well be that a TLS
> implementation doesn't know if its X509 validation code will support
> them as it hands the certificate to a
On Sat, Jul 9, 2016 at 7:37 AM Salz, Rich wrote:
> > If people are in favor of this, I will prepare a PR.
>
> +1
>
+1
David
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
OpenSSL determines which certificate to use during ClientHello processing,
but it has a mode where, if intermediates were not explicitly configured
and only a leaf, it path-builds right before sending the Certificate
message. But I don't see any reason why it can't be changed to compute this
earlie
[Changing subject since the other thread is about something else.]
On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara
wrote:
> > ### Signature Algorithms
> >
> > * In TLS 1.2, the extension contained hash/signature pairs. The pairs are
> > encoded in two octets, so SignatureScheme values have b
On Tue, Jul 12, 2016 at 1:47 PM David Benjamin
wrote:
> [Changing subject since the other thread is about something else.]
>
> On Tue, Jul 12, 2016 at 12:16 AM Ilari Liusvaara
> wrote:
>
>> > ### Signature Algorithms
>> >
>> > * In TLS 1.2, the ext
On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara
wrote:
> On Tue, Jul 12, 2016 at 05:47:26PM +0000, David Benjamin wrote:
> > [Changing subject since the other thread is about something else.]
> >
> > I believe, as the text stands right now, RSA-PSS and EdDSA do *not* exi
On Tue, Jul 12, 2016 at 4:17 PM Ilari Liusvaara
wrote:
> On Tue, Jul 12, 2016 at 07:53:41PM +0000, David Benjamin wrote:
> > On Tue, Jul 12, 2016 at 3:29 PM Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > Right, there is a risk of int
Hey folks,
I would like to remove the missing_extension MUSTs on the server side. Full
justification in the PR.
https://github.com/tlswg/tls13-spec/pull/544
On the client, it is perfectly feasible to mandate a particular alert
value. The check is very straight-forward. On the server, however, thi
t; reliable 1RTT (with the exception of HRR).
On Wed, Jul 13, 2016 at 8:12 AM Hubert Kario wrote:
> On Wednesday 13 July 2016 05:23:53 David Benjamin wrote:
> > I don't believe an implementation which fails to send supported_groups,
> > etc., in 1.3 would ever lea
ular
error code passes #1 (the special-case is not useful and such a peer would
not be able to handshake against correct implementations anyway), so I'm
not willing to sacrifice #2 for it.
On Wed, Jul 13, 2016 at 10:02 AM David Benjamin
wrote:
> On Wed, Jul 13, 2016 at 3:31 AM Dave Garrett
On Wed, Jul 13, 2016 at 11:06 AM Hubert Kario wrote:
> On Wednesday 13 July 2016 14:43:58 David Benjamin wrote:
> > To be clear, I am not at all opposed to useful errors or strict policing
> of
> > what the peer sends. That's all great. Indeed the linked test below makes
&
Every time resumption_context is used, it's fed into the PRF hash.
Handshake Context gets hashed since that actually expands to the full
concatenation and we want to be able to maintain a rolling hash.
But resumption_context is always a short value and is already the size of
the PRF hash. (If not r
ensions, cipher suites, and curves.) I expect this will make it much
less likely anyone will accidentally ship a server that rejects unknown
versions (or whatever else).
On Mon, Jul 18, 2016 at 1:08 PM Hanno Böck wrote:
> Hi,
>
> Recently both Adam Langley [1] and David Benjamin [2] indi
ion based mechanism to indicate TLSv1.3,
> > Just quick: This was discussed yesterday, David Benjamin had an
> > interesting proposal, but it was largely met with resistance. So from
>
> I had some follow-up discussion with David and a few others later in the
> day. One point th
On Sat, Jul 23, 2016 at 3:37 AM Brian Smith wrote:
> Hubert Kario wrote:
> > I'm quite sure that if I were sending a huge extension or many big
> extensions,
> > the percentage of servers that are incompatible to them would be
> similar, if
> > not worse. A relatively small 3KiB client hello alr
Hi folks,
I'm not sure how this process usually works, but I would like to reserve a
bunch of values in the TLS registries to as part of an idea to keep our
extension points working. Here's an I-D:
https://tools.ietf.org/html/draft-davidben-tls-grease-00
(The name GREASE is in honor of AGL's rust
On Mon, Jul 25, 2016 at 6:32 PM David Benjamin
wrote:
> Hi folks,
>
> I'm not sure how this process usually works, but I would like to reserve a
> bunch of values in the TLS registries to as part of an idea to keep our
> extension points working. Here's an I-D:
>
On Mon, Jul 25, 2016 at 7:23 PM Viktor Dukhovni
wrote:
> On Mon, Jul 25, 2016 at 10:32:29PM +0000, David Benjamin wrote:
>
> > I'm not sure how this process usually works, but I would like to reserve
> a
> > bunch of values in the TLS registries to as part of an idea
On Tue, Jul 26, 2016 at 6:56 AM Hubert Kario wrote:
> On Monday, 25 July 2016 22:32:29 CEST David Benjamin wrote:
> > I would like to fix this by reserving a few values in our registries so
> > that clients may advertise random ones and regularly exercise these
> > cod
; PS: As chair, I try to deal with/deflect as many of these procedural
> issues as possible, but if you want to know more please let me know
> off-list. This actually goes for anybody on the list.
>
>
> > On Jul 25, 2016, at 18:32, David Benjamin wrote:
> >
> > Hi f
On Wed, Jul 27, 2016 at 6:11 AM Hubert Kario wrote:
> On Tuesday, 26 July 2016 16:27:32 CEST Brian Smith wrote:
> > Hubert Kario wrote:
> > > TLS 1.3 170 3.8742
> > > TLS 1.4 183 4.1705
> > >
> > > size e/1356
REASE values {0x0A0A, 0x1A1A …. }. If I am missing something,
>> please clarify me.
>>
>>
>>
>> Regards,
>>
>> R Ashok
>>
>>
>> --
>>
>> Raja Ashok VK
>> 华为技术有限公司 Huawei Technologies Co., Ltd.
o,
> total or partial
> disclosure, reproduction, or dissemination) by persons other than the
> intended
> recipient(s) is prohibited. If you receive this e-mail in error, please
> notify the sender by
> phone or email immediately and delete it!
>
> *From:* David Benjamin [mailto
ways that
violate the TLS standard, thus enabling the testing of many scenarios that
would be otherwise difficult to obtain with a standard stack. We (David
Benjamin and Eric Rescorla) have been getting it to work with NSS and
wanted to let others know in case they might find it useful.
This syste
In general one has to generate the directional traffic keys independently
due to read/write epochs changing at different times, so I'd prefer it left
as is. (In BoringSSL, we also generate the directional keys independently.
I'd often wished that TLS 1.2 was the same.)
The switch from handshake to
Amusingly, Keith and I appear to have crossed mid-air in our respective
requests to change KeyUpdate, so this will be a fun collision. Mine is a
tad larger of a change I'm afraid.
We've currently implemented KeyUpdate in our in-progress TLS 1.3 code, but
we've for now ignored the requirement for t
On Thu, Aug 18, 2016 at 9:35 AM Ilari Liusvaara
wrote:
> > > David Bejamin already posted a PR about that. Doesn't clearly say
> > > that unknown reason handling.
> > >
> >
> > Yeah, I read the list before the PRs. I'll take a look but if you want to
> > comment that would be great.
>
> The only
On Thu, Aug 18, 2016 at 11:54 AM Eric Rescorla wrote:
> On Thu, Aug 18, 2016 at 8:47 AM, 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 w
On Thu, Aug 18, 2016 at 1:08 PM Benjamin Kaduk wrote:
> On 08/17/2016 11:29 PM, David Benjamin wrote:
>
> However, we lose the "free" (really at the cost of this unboundedness
> problem) generation-based bidirectional KeyUpdate sync. Depending on what
> we want out of K
te
> its send keys and send a KeyUpdate. If the
> desired_minimum_receive_generation is greater than the current send
> generation plus one, the receiver SHOULD abort."
>
Nit: Probably should explicitly say to fail with illegal_parameter or so.
> -Keith
>
> On Thu, A
On Fri, Aug 19, 2016 at 2:35 PM Geoffrey Keating wrote:
> Peter Gutmann writes:
>
> > The problem is that 7919 doesn't say "I want to do DHE, if possible
> > with these parameters", it says "I will only accept DHE if you use
> > these parameters, otherwise you cannot use DHE but must drop back t
On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara
> wrote:
>
>> On Thu, Sep 01, 2016 at 05:48:02AM -0700, Eric Rescorla wrote:
>> > On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario wrote:
>> > >
>> > > I'm afraid that requiring the server to keep
On Thu, Sep 1, 2016 at 11:25 AM Eric Rescorla wrote:
> On Thu, Sep 1, 2016 at 8:22 AM, Ilari Liusvaara
> wrote:
>
>> On Thu, Sep 01, 2016 at 02:29:00PM +, David Benjamin wrote:
>> > On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla wrote:
>> >
>> &g
On Thu, Sep 1, 2016 at 5:29 PM Ilari Liusvaara
wrote:
> On Thu, Sep 01, 2016 at 02:20:02PM -0700, Eric Rescorla wrote:
> > On Thu, Sep 1, 2016 at 2:09 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > > I tried to implement this, and discovered an issue:
> > >
> > > The client
lo is not
compatible with TLS 1.2's ServerHello. The first message may even not be
ServerHello and instead HelloRetryRequest.
David
On Wed, Jul 27, 2016 at 4:02 PM Sean Turner wrote:
>
> > On Jul 26, 2016, at 11:11, David Benjamin wrote:
> >
> > 1) “Updates: 5246 (if approved
Huh. I agree that text is weird. We should probably remove it. I think we
actually get something akin to what you suggest basically implicitly:
Servers aren't allowed to send unsolicited extensions, so your SH and EE
parsers should be rejecting any unknown extensions. If you combine that
with not
I have no involvement in systems that would want this (our implementation
just ignores it), but it seems a TLS-style registry would be better than
using OIDs anyway. Concretely:
A CertificateExtension is a hint to the client about what kind of
certificates are acceptable. We have a registry of u16
Apologies, I hit 'Send' too early. Finished a sentence below:
On Sun, Sep 4, 2016 at 1:41 PM David Benjamin wrote:
> I have no involvement in systems that would want this (our implementation
> just ignores it), but it seems a TLS-style registry would be better than
>
On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario wrote:
> On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote:
> > I've finally gotten to uploading
> > https://tools.ietf.org/html/draft-davidben-tls-grease-01 which hopefully
> > resolves the procedural issues
On Mon, Sep 5, 2016 at 10:59 AM Hubert Kario wrote:
> On Monday, 5 September 2016 14:48:55 CEST David Benjamin wrote:
> > On Mon, Sep 5, 2016 at 7:07 AM Hubert Kario wrote:
> > > On Friday, 2 September 2016 18:53:45 CEST David Benjamin wrote:
> > > > I&
On Mon, Sep 5, 2016 at 5:46 PM Andrei Popov
wrote:
> Ø A CertificateExtension is a hint to the client about what kind of
> certificates are acceptable. We have a registry of u16s for them. Clients
> ignore extensions they don't understand, so it is ultimately on the server
> to check the certifi
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
tra
est,
>
> Antoine
>
>
> Le 2016-09-07 05:49, Joseph Salowey a écrit :
>
> 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,
>
&g
On Wed, Sep 7, 2016 at 2:21 PM Eric Rescorla wrote:
> On Wed, Sep 7, 2016 at 11:19 AM, Andrei Popov
> wrote:
>
> > > the only popular stack I found that does not seem to send alerts is
> > > the schannel from Microsoft
>
> To clarify, schannel does generate alerts per RFC, but the HTTP stack
> (
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
v
On Mon, Sep 12, 2016 at 7:35 PM Jeffrey Walton wrote:
> On Wed, Dec 9, 2015 at 8:02 PM, Salz, Rich wrote:
> > OpenSSL just landed our chacha/poly implementation into master. We pass
> the
> > RFC test vectors, looking for other implementations to test against.
>
> Sorry to dig up an old thread.
On Wed, Sep 14, 2016 at 11:46 AM Benjamin Kaduk wrote:
> On 09/14/2016 04:56 AM, Hubert Kario wrote:
>
> First, I don't think that the argument that the current version scheme doesn't
> lend itself to future-proofing is correct. Just as with GREASE, browsers can
> send much higher version than th
On Fri, Sep 16, 2016 at 4:29 PM Andrei Popov
wrote:
> At the very least, if version is negotiated as extension it must be the
very first extension advertised.
I don't think it's a good idea to impose extension ordering requirements.
Agreed. If we're concerned with the order, I suppose are other
Hi folks,
We've run into some problems with client certificate alerts in Chrome that
I'd like to fix going forward.
The first is easy. handshake_failure is an unhelpful alert for server which
required client certs. This confuses users, so we're planning to
heuristically map it to a client certifi
Hi folks,
I've just uploaded this PR to slightly tweak SignatureScheme numbering:
https://github.com/tlswg/tls13-spec/pull/641
In principle, we should only have needed to burn values starting with known
HashAlgorithms, but TLS 1.2 said:
signature
This field indicates the signature algor
On Tue, Sep 20, 2016 at 11:33 AM Ilari Liusvaara
wrote:
> On Tue, Sep 20, 2016 at 03:07:51PM +0000, David Benjamin wrote:
> > Hi folks,
> >
> > I've just uploaded this PR to slightly tweak SignatureScheme numbering:
> > https://github.com/tlswg/tls13-spec/pull/641
On Tue, Sep 20, 2016 at 2:14 PM Hubert Kario wrote:
> On Tuesday, 20 September 2016 15:56:01 CEST David Benjamin wrote:
> > On Tue, Sep 20, 2016 at 11:33 AM Ilari Liusvaara <
> ilariliusva...@welho.com>
> >
> > wrote:
> > > On Tue, Sep 20, 2016 at
uot;pull request". :-)
David
Thanks,
Andrei
-Original Message-
From: Anders Rundgren [mailto:anders.rundgren@gmail.com]
Sent: Tuesday, September 6, 2016 8:36 AM
To: Peter Gutmann ; David Benjamin <
david...@chromium.org>; Andrei Popov ; Ilari
Liusvaara ; tls@ietf.org
Subject: R
CertificateRequestExtension certificate_extensions<0..2^16-1>;
} CertificateRequest;
Nick
On Thu, Sep 22, 2016 at 6:26 PM David Benjamin
wrote:
On Tue, Sep 6, 2016 at 1:03 PM Andrei Popov
wrote:
> But it's OID-specific how the matching works, isn't it?
Correct, and
On Sun, Sep 25, 2016 at 5:49 PM Adam Langley wrote:
> On Sun, Sep 25, 2016 at 2:35 PM, Henrick Hellström
> wrote:
> > Then again, the ASN.1 module in
> https://datatracker.ietf.org/doc/rfc5280/
> > says differently. Strictly speaking, RFC 3279 does not override the PKIX
> > specification when it
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
On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara
wrote:
On Sat, Oct 08, 2016 at 01:03:21AM +, Nick Sullivan wrote:
> 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 m
duce the complexity of
TLS 1.3 implementations that don't need these features.
Nick
On Sat, Oct 8, 2016 at 8:06 AM David Benjamin wrote:
On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara
wrote:
On Sat, Oct 08, 2016 at 01:03:21AM +, Nick Sullivan wrote:
> There has been a lot of discussio
To add to that, in out-of-order transports, whether a message was sent over
0-RTT or not may not even be very well-defined. If QUIC originally sent
data over 0-RTT but had to retransmit it after the full connection
parameters are available, I believe it will use those.
Even in an in-order transpor
Even without the Finished computation, rejecting a CertificateRequest would
hit the same unboundedness problem the previous generation of KeyUpdate had.
Our implementation currently treats all post-handshake CertificateRequests
as a fatal error. I think the only context where we'd conceivably chan
My interpretation was:
1. Client and server remember the previous selected ALPN protocol in the
session.
2. The client may offer whatever ALPN protocols it likes. It does not need
to match the previous offer list, though it presumably will unless you've
got a persistent session cache or so.
3. T
#x27;s configuration changed.) But after that, all your
new tickets are at h3 and the steady state is 0-RTT-capable again.
David
>
>
> Kyle
>
>
>
> *From:* Eric Rescorla [mailto:e...@rtfm.com]
>
>
> *Sent:* Wednesday, October 12, 2016 4:03 PM
>
> *To:* David
Sounds reasonable.
One concern is the F5 bug's failure mode was a timeout rather than an
error, so, if you take away padding, the allowance in C.3 will not save
heterogenous deployments where some servers do 1.3 and some are old F5
servers. But given we're talking about a straight-up server bug no
On Mon, Oct 31, 2016 at 6:34 PM Kurt Roeckx wrote:
On Mon, Oct 31, 2016 at 07:11:10PM +, David Benjamin wrote:
> On Mon, Oct 31, 2016 at 2:57 PM Ilari Liusvaara
> wrote:
>
> > On Mon, Oct 31, 2016 at 06:43:52PM +, Matt Caswell wrote:
> > > A few supp
On Mon, Nov 7, 2016 at 6:50 PM Benjamin Kaduk wrote:
(was Re: [TLS] PR#625: Change alert requirements)
Digging up an old sub-thread...
On 09/20/2016 08:03 AM, Eric Rescorla wrote:
in Record Layer there's the following text:
legacy_record_version : This value MUST be set to { 3, 1 } for al
I already hummed in the room, but I think it should stay as TLS 1.3. Either
of TLS 2 or TLS 4 makes the SSL/TLS silliness worse. One matches SSL 2.0
and the other just makes all this weirder. (Do we really want 2.0 < 3.0 <
1.0 < 1.1 < 1.2 < 4?)
TLS 1.3 is the natural next number and doesn't make a
On Tue, Nov 22, 2016 at 2:05 PM Olivier Levillain <
olivier.levill...@ssi.gouv.fr> wrote:
> Hi list,
>
> I am sorry for the very late answer concerning draft 18, but we
> (ANSSI) have several remarks after proof-reading the current
> specification.
>
> We are sorry for the multiple long messages.
On Thu, Dec 1, 2016 at 10:12 PM Peter Gutmann
wrote:
> Tony Arcieri writes:
>
> >There's already ample material out there (papers, presentations, mailing
> list
> >discussions, etc) which talks about "TLS 1.3".
>
> In other words, the TLS WG and a small number of people who interact with
> it
>
eers,
>
> Andrei
>
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Peter Gutmann
> Sent: Friday, December 2, 2016 12:33 AM
> To: Stephen Farrell ; David Benjamin <
> david...@chromium.org>; Tony Arcieri ; <
> tls@ietf.org>
&
On Mon, Dec 12, 2016 at 8:45 PM Martin Thomson
wrote:
> On 13 December 2016 at 12:43, Nick Harper wrote:
> > Right now, I believe it's legal for a client to send ClientHello, early
> > data, and end_of_early_data alert without reading any messages from the
> > server. This change would require a
Our implementation considers all post-handshake CertificateRequests to be a
fatal error to avoid this. We would do the same even with this proposal;
it's an unnecessary complexity (which translates to security risk). If the
protocol is such that the client will always bulk-disavow a burst of
unexpe
It's possible I'm misunderstanding your message here (I'm a little confused
by the mention of combining normal certificate authentication with an
external PSK), but TLS 1.3 already allows doing both PSK and (EC)DH. That's
the psk_dhe_ke mode, rather than the psk_ke mode. It's signaled by the
server
On Tue, Dec 27, 2016 at 4:44 PM Joseph Birr-Pixton
wrote:
Hi folks,
It appears to me that HRR is a pretty large and tricky source of
complexity in TLS1.3. Judging by the implementations page, 40% don't
support it right now. It's *precisely the kind of thing* that vendors
could easily ship broken
Done. Let me know if I did any of that incorrectly.
(Sorry about the delay. I've been some combination of suffering from a
cold, on vacation, or at conferences for the past month---usually more than
one at a time!)
On Tue, Jan 3, 2017 at 8:59 AM Sean Turner wrote:
I appears that we’ve got enoug
So, having uploaded draft-ietf-tls-grease-00, I would now like to rewrite
large chunks of it. The draft is currently defined for TLS 1.2, but it
probably makes sense to order it after TLS 1.3.
TLS 1.3 also adds a many new extension points, and we can expect new TLS
1.3 implementations popping up i
On Wed, Jan 18, 2017 at 8:15 PM Martin Thomson
wrote:
On 19 January 2017 at 14:04, Kazu Yamamoto wrote:
> Should we also add grease values for key_share?
supported_groups code points should cover that, but if you are asking
if we should spend bytes on sending shares for bogus groups, that's a
q
On Mon, Jan 30, 2017 at 4:45 PM Adam Langley wrote:
On Mon, Jan 30, 2017 at 1:41 PM, Scott Fluhrer (sfluhrer)
wrote:
> My question: in TLS 1.3, if the client inserts an extension of a type that
> the server does not recognize, how must the server behave? Is it required
> that the server just ig
I think this is much clearer, except for one bullet point below:
On Thu, Feb 2, 2017 at 10:22 AM Russ Housley wrote:
> [...]
> - If PSK and (EC)DH are being used together, then the server will:
>
> -- sends a "pre_shared_key" extension to indicate the selected
> key;
>
> -
301 - 400 of 572 matches
Mail list logo
