On Monday, July 13, 2015 10:30:06 am Martin Rex wrote:
> Section 7.4.1.4 Hello Extensions and its subsections are clearly IRRELEVANT
> for a client that does not use Hello Extensions.
If you want to put it that way, sure, however they are NOT irrelevant for a
_server_ that does use hello extensio
On Monday, July 13, 2015 01:11:29 pm Andrei Popov wrote:
> My preference would be to keep the client explicitly advertising its
> capabilities, and the server strictly honoring the client-advertised
> capabilities. And since the concept of "default algorithms" confuses people,
> let's just get r
On Monday, July 13, 2015 10:47:11 pm Viktor Dukhovni wrote:
> Furthermore, DANE-EE(3) clients and certificate pinning clients
> cannot use anon_DH, they still a recognizable certificate from the
> server, they just often don't need a recognizable signature. Even
> DANE-TA(2) clients might be able
On Wednesday, July 15, 2015 10:15:23 am Ilari Liusvaara wrote:
> Let's review: draft-ietf-tls-tls13-07
Eric obviously does all the heavy lifting here, but I can reply to a
few bits in the areas I've touched.
> (Note: I omitted some stuff I saw recently discussed (e.g. pruning
> unused crypto algo
In PR 188 for TLS 1.3, I pruned down the allowed elliptic curves to just the
ones actually used. (per Sean's recommendation) One point of discussion between
Eric and myself: sect571r1. I'm in favor of keeping it, but not very strongly.
Eric suggested removing it. It does get some use, though qui
On Wednesday, July 15, 2015 05:06:37 pm Tanja Lange wrote:
> > The main reason I think this warrants discussion is that dropping it would
> > drop the maximum bits here, which whilst obviously not the only factor to
> > take into account, will possibly not be desired by some. The main arguments
On Wednesday, July 15, 2015 05:39:26 pm Dave Garrett wrote:
> It's the most used of the rarely used curves.
This statement is potentially confusing, actually, because in comparison to
P256 _everything_ is rarely used when it comes to ECDHE
On Wednesday, July 15, 2015 06:06:37 pm Tony Arcieri wrote:
> On Wed, Jul 15, 2015 at 2:39 PM, Dave Garrett wrote:
> > It's the most used of the rarely used curves.
>
> I think all "rarely used curves" should be removed from TLS. Specifically,
> I think it wo
On Wednesday, July 15, 2015 09:42:51 pm Dan Brown wrote:
> What about sect571k1, a Koblitz curve, aka NIST curve K-571? (By the way it
> has no unexplained constants...). Has it been removed already, or does the
> question also refer K-571 too?
Already dropped. That's obviously not irreversible,
On Wednesday, July 15, 2015 10:42:54 pm Dave Garrett wrote:
> The stats also show 1575 "support" it, so I'm not sure what's going on there
> specifically. (if someone can explain this bit of those stats, please do)
Actually, now that I think about it, it could
On Wednesday, July 15, 2015 10:31:12 pm Tony Arcieri wrote:
> Binary curves in particular are showing warning signs of potential future
> security issues:
>
> https://eprint.iacr.org/2015/310.pdf
>
> I think even if we don't completely pare down the TLS curve portfolio to
> the list I suggested,
https://github.com/tlswg/tls13-spec/pull/201
I've finished up the WIPs I had been working on for the various discussions
we've been having on-list and submitted a PR. There's a lot in there, so review
and comments are welcome. Almost all of this has been discussed here at some
point to some deg
Brian Smith posted an RFE to GitHub a few months ago requesting "A mechanism is
needed to indicate that a session will not be resumed":
https://github.com/tlswg/tls13-spec/issues/137
The goal is to provide a simple way for either endpoint to request that the
master secret be forgotten ASAP to pr
On Fri, Jul 17, 2015 at 9:37 PM, Dave Garrett
wrote:
> Brian Smith posted an RFE to GitHub a few months ago requesting "A
> mechanism is needed to indicate that a session will not be resumed":
> https://github.com/tlswg/tls13-spec/issues/137
[...]
> I've written up
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 do any of the work that it would normally do to make the
> session resu
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
The current expectation is to separate extensions into unencrypted and
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 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 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
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
On Monday, July 20, 2015 12:27:42 am Eric Rescorla wrote:
> I think perhaps you have misunderstood the forward secrecy properties of the
> current draft. Unlike TLS 1.2 and previous, the current draft has a separate
> resumption master secret which is independently derived from the master
> secret
On Monday, July 20, 2015 01:31:15 pm Hugo Krawczyk wrote:
> Your question boils down to: Why is finished_secret derived from SS only
> and not from ES?
>
> First note that the issue only arises in the known_configuration case since
> in other cases ES and SS are the same.
> For the known_configura
On Tuesday, July 21, 2015 10:47:05 am Ilari Liusvaara wrote:
> I thought that Brainpool curves weren't removed (even if those aren't
> explicitly in), which are random prime curves.
>
> Also, the security of binary curves seems quite questionable.
Brainpool curves aren't in the TLS 1.3 draft, but
On Tuesday, July 21, 2015 07:04:14 am Eric Rescorla wrote:
> struct {
>select (Role) {
> case client:
>opaque identifier<0..2^16-1>;
>CipherSuite cipher_suite;// NEW
>Extension extensions<0..2^16-1>; /
I've updated the a la carte proposal again with some improvements to
readability. I've also added in the ECDHE PSK cipher suites in the current
draft, as they are required for this.
current WIP text:
https://github.com/davegarrett/tls13-spec/blob/alacarte/draft-ietf-tls-tls13.md#cipher-suites
di
On Wednesday, July 22, 2015 10:30:24 am Kyle Rose wrote:
> How about removing the RSA/ECDSA from the cipher suite, and making the
> SigAlgs extension mandatory for connections requiring authentication?
> That halves the number of cipher suites and eliminates an unnecessary
> redundancy, while keepi
On Wednesday, July 22, 2015 07:36:50 am Martin Thomson wrote:
> On 22 July 2015 at 02:29, Yoav Nir wrote:
> > PR at
> > https://github.com/tlswg/rfc4492bis/blob/master/draft-ietf-tls-rfc4492bis.xml
> > ?
>
> https://github.com/tlswg/rfc4492bis/pull/6
Could the cipher suite names be officially
On Wednesday, July 22, 2015 01:20:52 pm Martin Thomson wrote:
> I believe that renaming entries in the IANA registry is possible.
Negotiated FFDHE is renaming an extension identifier in the IANA registry, so
this is not an entirely new issue.
https://datatracker.ietf.org/doc/draft-ietf-tls-negoti
Consensus was my current WIP proposal is not viable, for some of the following
main reasons:
1) cost/benefit analysis doesn't seem to be worth it
2) backwards compatibility handling
3) some argue harder to implement; others argue easier
To start, I'll note that I have not submitted a PR yet.
Th
Hubert Kairo found quite a few more spots in need of explicit error
designations, which have been amended into PR #201.
https://github.com/tlswg/tls13-spec/pull/201
I just noticed one error in the current draft text that was wrong and added a
fix for that as well. The Server Hello section said t
On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote:
> Dave Garrett wrote:
> >
> > enum {
> >handshake_failure(40),
> >unsupported_cipher_suites(71), /* formerly insufficient_security */
> >u
On Thursday, July 23, 2015 07:09:49 am Hubert Kario wrote:
> vast swaths of web servers are misconfigured; introducing a more complex
> mechanism to server configuration when the existing situation is
> incomprehensible to many administrators won't help (and even many people that
> write the var
On Thursday, July 23, 2015 12:00:34 pm Viktor Dukhovni wrote:
> On Thu, Jul 23, 2015 at 11:43:45AM -0400, Dave Garrett wrote:
> > Plus, "MUST" use DHE or ECDHE for ALL connections, even back to TLS 1.0,
> > or abort with a fatal error.
>
> Who's going to p
On Thursday, July 23, 2015 01:10:30 pm Eric Rescorla wrote:
> On Thu, Jul 23, 2015 at 7:06 PM, Stephen Farrell
> wrote:
> > A suggestion - could we remove mention of anything that
> > is not a MUST or SHOULD ciphersuite from the TLS1.3 document
> > and then have someone write a separate draft that
On Thursday, July 23, 2015 06:49:06 am Aaron Zauner wrote:
> I mean I kinda agree that 'insufficent security' is a misleading name,
> but as it has been used for decades in TLS I'm a bit hesitant if it's a
> good idea to change the name now.
Alternate bikesheddy response: what about renaming it to
On Thursday, July 23, 2015 03:31:06 pm Aaron Zauner wrote:
> Fine with that. Now that I think about it again; I'm also fine with the
> original proposal. The thing is 'insufficient security' has a nicer ring
> to it than 'unsupported XYZ'.
It's wrong, though. If a server rejects a client connectio
On Thursday, July 23, 2015 10:52:59 pm Andrei Popov wrote:
> Rather than renaming and otherwise modifying the meaning of the existing
> alerts, would it be better to define new, more granular alerts in 1.3? We
> can’t ascribe new meanings to alerts generated by the code we’ve shipped in
> the pa
On Friday, July 24, 2015 01:50:31 am Andrei Popov wrote:
> > I'm proposing renaming "insufficient_security" to
> > "unsupported_cipher_suites", which is explicitly what it's been for since
> > TLS 1.0.
>
> Not quite. Insufficient_security alert is defined as follows:
> " Returned instead of hand
On Friday, July 24, 2015 06:43:17 am Hubert Kario wrote:
> And I completely agree. FREAK and Logjam wouldn't happen at all if we didn't
> drag with us stuff that was considered legacy 10 years ago.
>
> But stuff like "server MUST abort handshake if it sees export grade ciphers
> in
> Client Hel
On Friday, July 24, 2015 01:18:41 pm Hubert Kario wrote:
> On Friday 24 July 2015 12:57:42 Dave Garrett wrote:
> > To be clear, the wording I have in the PR is not this broad. It only
> > requires aborting if export ciphers were offered by a TLS 1.3+ client, not
> > just any c
I'm pretty sure some/all of this was likely mentioned elsewhere, but I don't
see any discussion on-list. (it was mentioned in part of the IETF 93 recording
I watched as this whole topic needing to go to the list, as well) There's also
related TODOs in the draft on this topic. Here's a start to t
On Saturday, July 25, 2015 01:18:49 pm Viktor Dukhovni wrote:
> I would go further, and say that "prohibiting RC4" in any sense
> that is more than prohibiting its use as the final outcome of a
> handshake would be a rather counter-productive strategy.
>
> Servers and clients are strongly encourag
On Monday, August 10, 2015 01:10:38 pm Andrei Popov wrote:
> > What sort of usecase you have in mind for this?
>
> This is to support a fairly common website design where the landing page does
> not require client auth, but subsequent request to a protected resource
> triggers client authenticati
On Monday, August 17, 2015 06:22:04 am Yaron Sheffer wrote:
> The record length field is limited by encrypted-length+2048. Shouldn't it be
> 1024? - "Each AEAD cipher MUST NOT produce an expansion of greater than 1024
> bytes".
See: https://github.com/tlswg/tls13-spec/issues/55
> Handshake_fail
On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote:
> On 17 May 2015 at 14:32, Dave Garrett wrote:
> > Is it really necessary to have a separate application_data_padded content
> > type? It'd be simpler to just keep using existing types but amend it with a
> > pa
On Saturday, August 22, 2015 03:36:21 pm Russ Housley wrote:
> > On Sunday, May 17, 2015 05:29:51 pm Tom Ritter wrote:
> >> On 17 May 2015 at 14:32, Dave Garrett wrote:
> >>> Is it really necessary to have a separate application_data_padded content
> >>> t
The topic of encrypting the content type came up again, and a core WG charter
goal is to encrypt as much as possible. To this end, I suggest we consider
going all the way in this area: headerless records. Each protected record would
contain nothing but an aead-ciphered struct with the bare minim
On Wednesday, August 26, 2015 05:11:01 pm Joseph Salowey wrote:
> It looks like we have good consensus on PR 169 to relax certificate list
> ordering requirements. I had one question on the revised text. I'm
> unclear on the final clause in this section:
>
> "Because certificate validation requi
On Thursday, August 27, 2015 02:48:15 pm Martin Thomson wrote:
> I've been looking at the latest TLS 1.3 spec and there are a lot of
> MUSTs that are completely toothless. To pick on a recent changeset:
>
> > The signature algorithm and hash algorithm MUST be a pair offered in the
> "signature_al
On Thursday, August 27, 2015 03:26:03 pm Eric Rescorla wrote:
> My problem is precisely the conflation of offering with negotiating. The way
> that
> many stacks work (for instance NSS) is that they negotiate the cipher suite
> *first* and then they check for the presence or absence of the relevan
PR to put this into writing:
https://github.com/tlswg/tls13-spec/pull/232
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Friday, August 28, 2015 11:08:35 am Salz, Rich wrote:
> Having discussions through github is a really bad idea.
You're right. I posted a stupidly long side-note in there. I intended to bring
it to the list too, which I'll do now.
On Friday, August 28, 2015 10:49:33 am Viktor Dukhovni wrote:
>
On Friday, August 28, 2015 12:33:31 pm Salz, Rich wrote:
> > And how often will the same client visit multiple servers at the same
> > transport address?
>
> Anyone who visits sites hosted by a CDN. And, I suspect, many large portals.
How's it done with IPv6, generally? Are there setups where ev
I actually had this in my old a la carte proposal. Here's the relevant section
posted separately, unedited, except for keeping the current list of RFCs with
anon that weren't in that proposal:
https://github.com/tlswg/tls13-spec/compare/master...davegarrett:unauthenticated
Dave
__
On Friday, August 28, 2015 04:21:53 pm Hanno Böck wrote:
> On Fri, 28 Aug 2015 19:17:39 +
> "Dang, Quynh" wrote:
> > I don't see a convincing reason to remove support of DSA in TLS 1.3.
>
> The reason is avoiding feature bloat. I think it makes a lot of sense
> to question the support of feat
On Friday, August 28, 2015 08:41:23 pm Jacob Appelbaum wrote:
> What do you suggest for the construction of the k value in DSA?
https://tools.ietf.org/html/rfc6979#section-3.2 ?
Also, we still have ECDSA, so the 'k' issue isn't going away. Should we cite
this RFC?
Dave
___
On Monday, August 31, 2015 08:43:16 am Hanno Böck wrote:
> If you can tell us
> a) who is using DSA
> b) why they think this has an advantage
> we can have a useful discussion.
Not to mention:
c) why they aren't switching to ECDSA
Dave
___
TLS mailing
On Tuesday, September 01, 2015 11:24:59 am Jeffrey Walton wrote:
> Regarding "who would actually use it": folks in US Federal (and those
> doing business in US Federal) don't have the choices that others have.
They, however, obviously do have the choice of switching from DSA to ECDSA, so
that arg
On Wednesday, September 16, 2015 07:23:34 pm Nico Williams wrote:
> On Wed, Sep 16, 2015 at 07:07:31PM -0400, Dave Garrett wrote:
> > This appears to just be a miscommunication.
>
> It is not.
>
> > The current poll is to remove anon ciphers in favor of raw public
> &g
On Thursday, September 17, 2015 05:46:39 pm Brian Smith wrote:
> Let's ask the browser vendors:
>
> Browser vendors, if web servers were to stop sending alerts during
> handshake failures, would you start doing version fallback when a
> connection is closed?
Well, what else would clients do inste
On Thursday, September 17, 2015 06:00:05 pm Brian Smith wrote:
> There's no evidence that the presence or absence of an alert when a
> connection is closed makes any positive difference in the security of any
> non-secure fallback mechanism. Keep in mind that the alerts during the
> handshake are N
On Friday, September 18, 2015 04:24:33 pm Brian Smith wrote:
> [...] unless a terrible mistake is made [...]
We're designing a security protocol to be used globally. We should be assuming
that not only will we have at least one terrible mistake, but also that there's
at least a few more that hav
On Saturday, September 19, 2015 04:06:37 pm Salz, Rich wrote:
> On Friday, September 18, 2015 04:25:39 pm Julien ÉLIE wrote:
> > The concern will be when TLS 1.2 is declared "flawed". Maybe one day it
> > will
> > be considered insecure; and then, compliant TLS implementations won't be
> > able t
On Monday, September 21, 2015 03:02:47 am Daniel Kahn Gillmor wrote:
> encrypted content type:
> ---
>
> https://github.com/tlswg/tls13-spec/pull/51
Basing the padding PR(s) on top of this might be a good idea, seeing as it's
desired to do this correctly.
One thought about d
On Tuesday, September 22, 2015 02:16:47 pm Julien ÉLIE wrote:
> Regarding vulnerable protocols, clients (and/or servers) could very well
> disable compression in TLS. And either never use compression or
> implement their own compression, according to their needs.
> It is what happened with BEAST
ding of any encrypted TLS record
> by an arbitrary size (from zero up to TLS record size limits) without
> introducing new content types. The design also enforces all-zero padding
> octets, which allows for quick detection of padding errors.
> "
>
> On Tue, Sep 22, 2015
On Wednesday, September 23, 2015 07:40:13 pm Salz, Rich wrote:
> Do folks know that we did decide on the MTI list already, and that it's a
> matter of ekr updating the draft? (It was decided at a PREVIOUS interim, it
> just fell through the cracks.)
The MTI list and the larger list of what can/
On Friday, September 25, 2015 01:10:37 pm Martin Rex wrote:
> Because it is not necessarily immediately obvious, you will need
> padding also for the Server Certificate handshake messages.
> And, because the key exchange is side-effected by properties of
> the Server Certificate, you may additional
On Tuesday, September 22, 2015 07:27:35 pm Sean Turner wrote:
> I’ve gone ahead and posted the minutes/list of decisions to:
>
> https://www.ietf.org/proceedings/interim/2015/09/21/tls/minutes/minutes-interim-2015-tls-3
Issue #185 has the "discuss-seattle" tag on it, but I don't see mention of it
On Sunday, October 04, 2015 01:58:09 pm Jeffrey Walton wrote:
> Is that necessarily true?
It should be apparent by now that the dominant opinion is that compression in
TLS is not worth the risk and not worth the time to attempt to deal with here.
Whether or not a generic compression algorithm co
On Sunday, October 04, 2015 02:09:49 pm Tony Arcieri wrote:
> If someone has produced a secure system for "compression side-channel
> resistant encryption", I haven't seen it.
I can think of a way to do this, but the people who want compression badly
probably won't like it due to the need to pad
On Sunday, October 04, 2015 02:48:19 pm Jeffrey Walton wrote:
> If I am reading things correctly: the group has effectively
> encountered a security problem, deemed it to be too hard for them, and
> then pushed it into another layer where folks are even less equipped
> to deal with it. Is that corr
On Sunday, October 04, 2015 03:00:33 pm Tony Arcieri wrote:
> On Sun, Oct 4, 2015 at 11:50 AM, Dave Garrett
> wrote:
> > I can think of a way to do this, but the people who want compression badly
> > probably won't like it due to the need to pad heavily.
> >
> &
On Wednesday, October 07, 2015 03:51:57 pm Martin Rex wrote:
> However, it is RECOMMENDED
> that implementations which support compression provide a configuration
> option allowing consumers to disable the use of compression in TLS.
Risky features like compression should be off by default.
Da
On Friday, October 09, 2015 12:49:02 pm Viktor Dukhovni wrote:
> I think this is "too clever" (a "hack" not a design) and offers
Every fix to an issue in this 20 year old protocol will be a hack.
> incomplete protection (does nothing to protect RSA key transport).
Better than none, for a very lo
On Friday, October 09, 2015 04:38:00 pm Viktor Dukhovni wrote:
> So even 2^{-48} is perhaps not quite low enough.
Going to a full 64-bit looks like a good idea to me. The loss of those 4 bytes
of entropy for old versions isn't likely to matter at all, though, please
correct me if someone thinks
On Saturday, October 10, 2015 04:28:28 pm Ilari Liusvaara wrote:
> On Sat, Oct 10, 2015 at 07:44:04PM +0200, Eric Rescorla wrote:
> > To be clear, the only thing that's allowed is SHA-1 in *certificates*.
> > It's forbidden in CertificateVerify.
>
> Isn't using it in certificates precisely more da
On Saturday, October 10, 2015 04:59:09 pm Viktor Dukhovni wrote:
> So long as SHA-1 self-signatures are still tolerated in root or
> self-signed end-entity certificates, I have no objection to TLS
> 1.3 specifying that a certificate signed with SHA-1 is not trusted
> even when issued by a trusted i
On Saturday, October 10, 2015 05:19:30 pm Viktor Dukhovni wrote:
> On Sat, Oct 10, 2015 at 05:11:56PM -0400, Dave Garrett wrote:
> > Note that opportunistic encryption is weird and getting
> > the whole document to be perfect for it might not be entirely doable, as
> > OE n
On Saturday, October 10, 2015 10:35:16 pm Viktor Dukhovni wrote:
> This is not difficult, it just requires not forgetting that there's
> more than one way to do (or not do) authentication, and that the
> TLS protocol needs to remain largely agnostic of the authentication
> model. Just deliver the
On Sunday, October 11, 2015 08:00:45 pm Viktor Dukhovni wrote:
> There's no reason for pessimism
Sorry, I have to laugh a bit here. :p
> we're not trying to deprecated deployed
> functionality, there is no TLS 1.3 deployed base.
Due to the fact that the vast majority of TLS implementations that
I'd like to get a sense of what the WG is willing to consider with regard to
SHA-1, rather than only Viktor and myself discussing this. Basically, I see 3
options:
Option 0: Do nothing new. SHA-1 is soft deprecated, but still a fully viable
option in TLS 1.3 if nothing better is installed.
Opti
On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> The observation is still valuable in the sense that prohibiting values
> > 1.3 would reduce the likelihood of a false positive by some
> miniscule amount. In other words, I agree with ekr here, though we
> could cap the value to 1.3
On Saturday, October 17, 2015 05:16:49 pm Eric Rescorla wrote:
> On Sat, Oct 17, 2015 at 2:08 PM, Dave Garrett
> wrote:
>
> > On Saturday, October 17, 2015 03:10:18 pm Martin Thomson wrote:
> > > The observation is still valuable in the sense that prohibiting values
>
On Saturday, October 17, 2015 05:53:57 pm Eric Rescorla wrote:
> On Sat, Oct 17, 2015 at 2:34 PM, Dave Garrett
> wrote:
> > A 64-bit sentinel can be trivially checked as a 64-bit uint.
>
> And a 56-bit value can be trivially checked by masking off the last byte.
> Or, memcmp
I'm in favor of this change as well. It annoys Viktor, as it changes the
fallback in a way that isn't ideal for some cases that trust the cert directly
or with OE, but I think it's better than the alternative.
Dave
On Wednesday, October 21, 2015 03:17:44 pm Eric Rescorla wrote:
> I think this
On Wednesday, October 21, 2015 03:56:09 pm Viktor Dukhovni wrote:
> Whether SHA-1 in the chain is used to make trust decisions is only
> known to the client, and the server MUST NOT preempt that by denying
> the client access to whatever chain it has on hand.
Can we please just fix this issue prop
Congrats on releasing an RFC that has day one 100% server support. :p
Dave
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
On Wednesday, October 21, 2015 07:56:13 pm Eric Rescorla wrote:
> https://github.com/tlswg/tls13-spec/issues/292
>
> Presently, RFC 4492 only specifies the EC points it can support in
> ServerHello, but does not let the server indicate which EC curves it
> supports. Unless I'm missing something, t
On Thursday, October 22, 2015 09:29:22 am Eric Rescorla wrote:
> From an implementation perspective, I wouldn't be surprised if client
> implementations choked on the server sending this. [...]
Hence my side-note that we should be explicit that it's for TLS 1.3+ (even if
it's implicit elsewhere).
On Thursday, October 22, 2015 02:18:30 pm Andrei Popov wrote:
> What if we just made an explicit exception for root cert hash algorithms and
> not constrained them by the client's alg list?
+1
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mail
On Thursday, October 29, 2015 11:00:04 am Viktor Dukhovni wrote:
> On Thu, Oct 29, 2015 at 03:07:58PM +0100, Hubert Kario wrote:
> > On Wednesday 21 October 2015 20:17:31 Dave Garrett wrote:
> > > Congrats on releasing an RFC that has day one 100% server support. :p
> >
On Sunday, November 01, 2015 07:53:50 pm Russ Housley wrote:
> I thought we already decided to remove compression from TLS 1.3.
We did.
See here:
https://www.ietf.org/mail-archive/web/tls/current/msg17941.html
On Thursday, October 08, 2015 10:10:51 pm Scott Arciszewski wrote:
> Compression has n
On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote:
> I'd like it to say:
>
> * The signature algorithms of self-signed certificates are
> not subject to any constraints on either the supplicant or
> the verifier. They are not required to match the supported
>
On Thursday, November 05, 2015 05:05:02 pm Viktor Dukhovni wrote:
> On Thu, Nov 05, 2015 at 04:59:18PM -0500, Dave Garrett wrote:
>
> > On Thursday, November 05, 2015 04:38:34 pm Viktor Dukhovni wrote:
> > > I'd like it to say:
> > >
> > >
On Friday, November 06, 2015 08:13:44 pm Eric Rescorla wrote:
> Update: we discussed this extensively in Yokohama and based on Watson's
> feedback and offline comments from David McGrew, the consensus was that we
> needed to add some sort of rekeying mechanism to support long-lived flows.
> Expect
On Friday, November 06, 2015 10:54:02 pm Eric Rescorla wrote:
> I don't believe time-based guidance is useful here, given that it's highly
> situation specific rather than derived from reasoning about the properties
> of the cipher.
One reason to have a regular interval between rekeys is to ensure
On Tuesday, November 17, 2015 02:14:00 pm Ilari Liusvaara wrote:
> All current registered/proposed ciphersuites that work in TLS 1.3 are
> *-GCM or *-POLY1305 ones (with DHE or ECDHE).
DHE AES CCM is still in the list, even after the changes in the current
proposal. ECDHE AES CCM is not as it's n
On Thursday, November 26, 2015 02:15:25 pm Ilari Liusvaara wrote:
> I actually looked at the Editors's Copy. The description is a mess: It
> seemingly first requires key_share extension, even for the first
> ClientHello... Now, that extension can't be empty... And then proceeds
> to say to omit it
HelloRetryRequest is annoying. Is there any way we can replace it with
something? I know our options are limited, here. We can't mandate offers for
everything, not just due to constrained environments, but also because
post-quantum keys could get too big.
The main thing that comes to mind would
1 - 100 of 235 matches
Mail list logo
