behaving correctly for GREASE allocated code points, while remaining
> buggy for the other (unallocated). code points.
> Yours,
> Daniel
>
> On Wed, Jun 13, 2018 at 2:06 PM, Alessandro Ghedini > wrote:
>
>> On Tue, Jun 12, 2018 at 12:27:39PM -0400, David Benjamin wrote:
>&
This is BoringSSL's interpretation as well. We don't support renegotiation
on the server at all, but our server still implements the
renegotiation_info extension in the degenerate case for the initial
handshake. It is vacuously true that all renegotiations we'll perform on
that connection are secur
On Tue, Jun 12, 2018 at 2:44 PM Christopher Wood <
christopherwoo...@gmail.com> wrote:
> On Tue, Jun 12, 2018 at 11:32 AM David Benjamin
> wrote:
> >
> > On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <
> christopherwoo...@gmail.com> wrote:
> >>
On Tue, Jun 12, 2018 at 2:01 PM Christopher Wood <
christopherwoo...@gmail.com> wrote:
> On Tue, Jun 12, 2018 at 10:55 AM Kyle Nekritz wrote:
> >
> > Since the Certificate message is sent in an encrypted record, the normal
> record padding mechanism (section 5.4) can be used, rather than sending
Hi all,
Now that TLS 1.3 is about done, perhaps it is time to reflect on the
ossification problems.
TLS is an extensible protocol. TLS 1.3 is backwards-compatible and may be
incrementally rolled out in an existing compliant TLS 1.2 deployment. Yet
we had problems. Widespread non-compliant servers
In both TLS 1.2 and TLS 1.3, SHA-256 isn't hardcoded per se. It's a
function of the cipher suite you negotiate (and also, separately, the
signature algorithm you negotiate). That said, in practice, both are pretty
solidly dependent on SHA-256. Most options involve it. AES-128-GCM and
ChaCha20-Poly1
.github.io/tls13-spec/draft-ietf-tls-tls13.html#rfc.section.9.3>.
I did not propose any new ideas in this document update, as this was just
about updating it to match the prior discussion of rebasing atop TLS 1.3.
David
On Thu, 07 Jun 2018 17:05:47 -0400 *David Benjamin
> >* wrot
This value would be kind of weird because this part of RFC 7919 is quite
complex. But if there's interest, I don't mind adding some.
But I think the TLS 1.2 bits of RFC 7919, particularly the rule you refer
to, were a mistake and are best ignored. The benefits of that document are
unrealizable to
On Thu, Jun 7, 2018 at 5:00 PM Benjamin Kaduk wrote:
> On Wed, Jun 06, 2018 at 03:08:28PM -0400, David Benjamin wrote:
> > Hi all,
> >
> > Apologies for the probably record time delay in actually updating this
> > thing. I like the graph... apparently -00 was expired f
nternet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
> Title : Applying GREASE to TLS Extensibility
> Author : David Benjamin
> Filename
ly TLS connections, though of course it must have a
> unique code point from other extensions used with QUIC. So it's not
> entirely clear how best to handle this,
>
> -Ekr
>
>
> On Thu, May 31, 2018 at 7:42 AM, David Benjamin
> wrote:
>
>> I probed
I probed a bunch of servers yesterday and found evidence of yet another
collision at 26! It's possible these are TLS-LTS implementations, but a lot
of them additionally only support RSA decryption ciphers, which makes this
seem unlikely. These servers do not appear to do anything with the
extension
On Tue, May 29, 2018 at 4:26 PM Andrey Jivsov wrote:
> On 05/29/2018 01:07 PM, David Benjamin wrote:
> > I'm not sure I follow this. So, in this scenario, you are the client.
> > You wish to support TLS 1.3, which requires supporting RSA-PSS in TLS
> > 1.3, and thi
I'm not sure I follow this. So, in this scenario, you are the client. You
wish to support TLS 1.3, which requires supporting RSA-PSS in TLS 1.3, and
this is fine. You are able to verify RSA-PSS signatures from the server at
TLS 1.3.
At the same time, you still talk to some TLS 1.2 servers, so you
BoringSSL and OpenSSL have are draft versions which use different version
numbers from the final RFC, so as not to collide. Early experimental
deployment is generally useful to help inform the final standard and flush
out any non-compliant TLS 1.2 implementations that may cause deployment
difficult
+1
On Mon, Apr 23, 2018 at 12:51 PM Eric Rescorla wrote:
> +1
>
> On Mon, Apr 23, 2018 at 9:33 AM, Sean Turner wrote:
>
>> All,
>>
>> tl;dr: If you object to the following early code point assignments 1) add
>> the compress_certificate in the TLS ExtensionType Registry and 2)
>> compressed_cert
On Mon, Mar 26, 2018 at 1:25 PM Salz, Rich wrote:
> Is it now impossible adding new things to TLS 1.2? I don't believe the WG
> understood that this would be the situation. So I disagree with your claim
> that this was our understanding of the situation.
>
> Okay, it turns out that David's neat
To make sure I understand the issue, the concern is that your decompression
function provides a chunk-by-chunk interface, there's a bug and the
division into chunks produces a different result? Or are you suggesting
that, with the same chunking pattern, the result is still non-deterministic
somehow
+1. If anything, the existing "buggy implementation" alert codes should get
folded together. (But I don't think it's worth making that change at this
stage either.) E.g. decode_error vs illegal_parameter vs
unexpected_message are rather useless distinctions and trying to get them
"right" adds compl
The data ultimately needs to be returned to the calling application,
presumably some HTTP parser, which in turn passes data up to more calling
code and so on. Conversely, the data must have been produced by some also
application-level process on the sender, some HTTP serializer, before it
was hande
FWIW, this was BoringSSL's interpretation as well. We don't consider
supported_versions an acceptable TLS 1.2 (or earlier) ServerHello
extension. I generally agree that we shouldn't add new unnecessary
combinations.
(TBH, I don't even consider the ability to advertise TLS 1.3 and TLS 1.1 on
the cl
I don't think we've observed this particular issue. We have observed
middleboxes which, when they see a ServerHello they can't parse (such as
the pre-draft-22 TLS 1.3 ServerHello), drop the ServerHello record on the
floor, but pass through any following application_data records as-is.
That's simila
What implementation are you working on? Section 5.1 says that, in
TLSPlaintext, the legacy_record_version "MUST be ignored for all purposes".
And, of course, any pre-1.3 middleboxes which hit this case are
non-compliant. That would imply they assume they can parse messages
following a ClientHello t
Dear all,
The recent release of Google Chrome 63 enabled (effectively) TLS 1.3
draft 22 for 95% of stable channel users who updated. (Our previous
results were on our beta channel.) While, in the past, we have
demurred[1] from providing details about problematic products we now
plan to alter that
On Thu, Dec 14, 2017 at 4:47 PM Ilari Liusvaara
wrote:
> On Tue, Dec 12, 2017 at 06:43:19PM -0600, Martin Thomson wrote:
> > On Tue, Dec 12, 2017 at 6:32 PM, Victor Vasiliev
> wrote:
> > > https://github.com/tlswg/certificate-compression/pull/8
> >
> > That's a lot cleaner. Thanks. Some minor
On Wed, Dec 13, 2017 at 5:39 PM Hanno Böck wrote:
> Hi,
>
> The deployment of TLS 1.3 was delayed because Internet middleboxes
> broke when they saw unknown TLS data.
>
> I guess it's plausible to assume that the same problem will show up
> with compressed certificates. Has any thought been given
On Fri, Dec 1, 2017 at 10:18 AM Eric Rescorla wrote:
> On Fri, Dec 1, 2017 at 6:47 AM, R du Toit wrote:
>
>> I want to provide some feedback that might be useful to the TLS WG:
>> Firefox Nightly TLS 1.3 (draft 22) sessions to tls13.crypto.mozilla.org
>> is triggering an interesting failure in a
As a source of some of those numbers, someone interested in actually
deploying TLS 1.3, and, most importantly, someone who would have to deal
with the fallout of that deployment, I can unequivocally say those are not
"very good" figures. They are completely implausible by orders of
magnitude. TLS 1
On Mon, Nov 13, 2017 at 8:25 PM Eric Rescorla wrote:
> On Mon, Nov 13, 2017 at 11:37 AM, Hubert Kario wrote:
>
>> On Saturday, 11 November 2017 10:21:11 CET David Schinazi wrote:
>> > Hello all,
>> >
>> > Currently TLS 1.3 specifies close_notify in the same way that TLS 1.2
>> did.
>> > I believ
I think this change is a good idea.
Our implementation actually does this already anyway. We are happy to
continue servicing writes even when the read half has consumed a
close_notify. I believe we inherited this behavior from OpenSSL, so it
should be there too. Go's crypto/tls implementation appe
On Tue, Nov 7, 2017 at 7:32 PM Eric Rescorla wrote:
> On Tue, Nov 7, 2017 at 4:25 PM, Watson Ladd wrote:
>
>> On Tue, Nov 7, 2017 at 4:05 PM, Jana Iyengar wrote:
>> > FWIW: In my experience middleboxes don't ossify based on what the spec
>> says,
>> > they ossify based on what they see on the w
On Tue, Nov 7, 2017 at 10:53 AM Hubert Kario wrote:
> In general +1, I like to see TLS 1.3 deployed ASAP and making the spurious
> failures as rare as possible is a good way to make that happen.
>
> that being said, I have few comments:
>
> On Monday, 6 November 2017 19:19:01 CET Eric Rescorla wr
On Thu, Sep 14, 2017 at 6:42 PM Jeffrey Walton wrote:
> To play devil's advocate, will the TLS stack need to keep a copy of
> the certificate or authorized origins (an origin group?) for future
> connections?
Implementations that don't retain enough information for it can always just
not offer
I believe what Raja is pointing out is that a server which accepts an ECDSA
*client* certificate has no way to advertise to the client which curves it
accepts. The signature algorithm list (and before TLS 1.2, the certificate
types) do advertise ECDSA as a whole, but not curves. E.g., a client with
> -Todd Short
> // tsh...@akamai.com
> // "One if by land, two if by sea, three if by the Internet."
>
> On Jul 5, 2017, at 1:22 PM, David Benjamin wrote:
>
> 0x is just the syntax for the maximum value in the enum.
>
> The intent was to match the HashAlgorithm regis
0x is just the syntax for the maximum value in the enum.
The intent was to match the HashAlgorithm registry which makes 0xFE and
0xFF the private use values, so I would say the enum is correct and the
IANA considerations text is wrong. This ensures we don't collide with any
existing TLS 1.2 pr
On Wed, Jun 14, 2017 at 7:31 PM David Benjamin
wrote:
> On Wed, Jun 14, 2017 at 6:47 PM Colm MacCárthaigh
> wrote:
>
>> On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin
>> wrote:
>>
>>> That is, it is not the identity of the bytes that matters much. It&#
On Wed, Jun 14, 2017 at 6:47 PM Colm MacCárthaigh wrote:
> On Wed, Jun 14, 2017 at 3:23 PM, David Benjamin
> wrote:
>
>> That is, it is not the identity of the bytes that matters much. It's
>> whether the connection has been confirmed when you perform an unsafe
>&
On Wed, Jun 14, 2017 at 5:01 PM Andrei Popov
wrote:
>
>- What if the server receives data with the 0-RTT boundary spanning an
>HTTP/2 frame? Is that a 0-RTT request? 1-RTT? Invalid?
>
> It appears safe to treat such data as 0-RTT; only the application can make
> this call, and it needs in
On Wed, Jun 14, 2017 at 2:17 AM Petr Špaček wrote:
>
>
> On 13.6.2017 22:55, Ilari Liusvaara wrote:
> > On Tue, Jun 13, 2017 at 06:57:05PM +, Andrei Popov wrote:
> >> Regarding RFC language, I think we could be more specific:
> >>
> >>
> >>
> >> 1. A TLS implementation SHOULD/MUST only send 0
On Wed, Jun 7, 2017 at 4:29 PM Ilari Liusvaara
wrote:
> On Wed, Jun 07, 2017 at 05:38:59AM +, Raja ashok wrote:
> > Hi Victor & Alessandro,
> >
> > I have gone through the draft and I am having a doubt.
> >
> > > The extension only affects the Certificate message from the server.
> > > It
On Tue, May 23, 2017 at 1:34 PM Benjamin Kaduk wrote:
> My initial thoughts...
>
>
> On 05/23/2017 06:50 AM, Markulf Kohlweiss wrote:
>
> I am paraphrasing a long thread on the issue that we had within
> the miTLS development team, and I am primarily commenting on the
> analysis aspects. I also h
Seeing as this utterly ridiculous ticket_age_add thing is partially my
fault, I suppose I should respond:
On Fri, May 19, 2017 at 4:10 PM Colm MacCárthaigh
wrote:
> > And then separate to all of the above, and lower priority:
>> >
>> > * There's a contradiction between the obfuscated ticket age
I too am in favor and willing to review it.
On Tue, May 16, 2017 at 9:25 AM Salz, Rich wrote:
> In favor, will review.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_
This seems overly complicated. Why implement a parallel key share mechanism
rather than merely defining a new NamedGroup value?
Using your example of Google's recent New Hope experiment, I would imagine
defining, say, NamedGroup.cecpq1. Let its key_shares be the concatenation
of New Hope and X2551
On Wed, Apr 5, 2017 at 12:14 PM Benjamin Kaduk wrote:
> On 04/05/2017 09:21 AM, Eric Rescorla wrote:
>
> On Wed, Apr 5, 2017 at 7:12 AM, Ryan Sleevi
> wrote:
>
> Does cached-info not represent a privacy info-leak by disclosing past
> sessions prior to authenticating the new session? Versus compr
I think it's a typo. My understanding is EndOfEarlyData was meant to be in
the transcript.
David
On Fri, Mar 24, 2017 at 9:27 AM Matt Caswell wrote:
> In draft-19 EndOfEarlyData was changed from an alert to a handshake
> message. Therefore I would have expected to see it included in the
> calcu
printing concern doesn't seem
> that serious in any case.
>
> -Ekr
>
>
> On Wed, Mar 15, 2017 at 1:25 PM, David Benjamin
> wrote:
>
> draft-ietf-tls-rfc4492bis-15, section 5.11, contains the following text:
>
>Since there are some implementation of the X25519
draft-ietf-tls-rfc4492bis-15, section 5.11, contains the following text:
Since there are some implementation of the X25519 function that
impose this restriction on their input and others that don't,
implementations of X25519 in TLS SHOULD reject public keys when the
high-order bit of t
How's this look? https://github.com/tlswg/rfc4492bis/pull/37
On Wed, Mar 15, 2017 at 2:45 PM Yoav Nir wrote:
> There is (going to be a re-spin). There already is a PR there.
>
> If you can make a PR to solve your issue, that would be great.
>
> On 15 Mar 2017, at 19:20, D
If there's to be a respin anyway, I have another small editorial comment:
https://github.com/tlswg/rfc4492bis/issues/36
On Wed, Mar 15, 2017 at 11:22 AM Eric Rescorla wrote:
> FWIW, there's a lot here, but I think it's all essentially editorial, so
> it shouldn't
> be that hard to clean up.
>
>
On Sun, Mar 12, 2017 at 8:09 PM Martin Thomson
wrote:
> On 13 March 2017 at 10:55, Brian Smith wrote:
> >> So, I'd prefer to bring session IDs back, and
> >> to arrange things so that they're always server-generated.
> >
> > Even in earlier versions, session IDs were not required with
> > resump
On Tue, Mar 7, 2017 at 12:49 PM Eric Rescorla wrote:
> On Tue, Mar 7, 2017 at 9:44 AM, Roelof Du Toit > wrote:
>
> All,
>
>
>
> The current language in
> https://tlswg.github.io/tls13-spec/#rfc.section.4.1.4 states:
>
> As with ServerHello, a HelloRetryRequest MUST NOT contain any extensions
> t
On Mon, Mar 6, 2017 at 5:52 PM Martin Thomson
wrote:
> On 7 March 2017 at 08:43, David Benjamin wrote:
> > To clarify, our interpretation of the spec was that it is the encrypted
> > data, not unencrypted data.
>
> Well, clearly we disagree. To be clear, I don&#x
smaller value in the
ticket to compensate for this difference.
David
On Mon, Mar 6, 2017 at 1:06 AM Martin Thomson
wrote:
> (Adding Filippo, who wrote the original change.)
>
> I just did some spelunking of the archives, and poking at boring SSL.
> I found that David Benjamin mentions
Looks like TLS 1.3 already allows this for CT, though not OCSP. Would take
all of four characters to fix. See this table:
https://tlswg.github.io/tls13-spec/#rfc.section.4.2
One of the nice things about using TLS-style extensions in
CertificateRequest is any ClientHello => (Server)Certificate exte
This is a minor comment and purely aesthetic thing. Apologies for the
lateness in noticing. Hopefully it's not too late:
In TLS 1.3, we dropped the "ecdh_" prefix on ecdh_x25519 and ecdh_x448 when
we split signatures from NamedCurve/Group. The documents should probably
match in naming one way or a
On Wed, Feb 15, 2017 at 2:49 PM David Wong
wrote:
> On Feb 15 2017, at 7:27 pm, Andrei Popov
> wrote:
>
> Yes, I agree that it is useful to mention this in the spec.
>
>
>
>
> It would be nice is to have two different PRs solving this issue. One
> mentioning this as a potential issue that the ap
NewSessionTicket always includes in-handshake client auth. The resumption
secret can't even be derived without it.
On Tue, Feb 14, 2017 at 10:21 AM David Wong
wrote:
> I can see this problem even in the case where the client sends an empty
> Certificate message during the handshake. If the appli
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;
>
> -
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
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
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
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
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
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
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
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
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 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
>
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.
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 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
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
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
#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
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
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
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
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
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
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 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
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
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
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
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
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
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
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
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 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.
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 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
> (
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
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
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
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 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
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
>
301 - 400 of 505 matches
Mail list logo
