On Fri, Dec 18, 2015 at 2:45 PM, Christian Huitema
wrote:
> The ladder diagram describing the 0-RTT exchange is simple enough, as seen
> in this extract:
>
> Client Server
>
> ClientHello
>+ KeyShare
>+ EarlyD
Does anyone object to this change? If not, I intend to merge it in this
weekend.
-Ekr
On Fri, Dec 18, 2015 at 7:47 AM, Cedric Fournet
wrote:
> The surprise is that breaking one key also yields the ability to truncate
> traffic protected with another key. We agree that we don't have any
> parti
On Sun, Dec 20, 2015 at 5:13 PM, Brian Smith wrote:
> Adam Langley wrote:
>
>> On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith
>> wrote:
>> > That is, it seems it would be better to use HKDF-SHA512 instead of
>> > **HKDF-SHA256**.
>>
>> I assume that you mean for TLS 1.3 since you mention HKDF?
>
On Sun, Dec 20, 2015 at 5:50 PM, Brian Smith wrote:
> Eric Rescorla wrote:
>
>> On Sun, Dec 20, 2015 at 5:13 PM, Brian Smith
>> wrote:
>>
>>> Adam Langley wrote:
>>>
>>>> On Fri, Dec 18, 2015 at 1:43 PM, Brian Smith
>>>> wro
On Mon, Dec 21, 2015 at 5:49 PM, Christian Huitema
wrote:
> The handshake hash specification in section 7.1 says:
>
You're referring the editor's copy (WIP-11), right?
> Where handshake_hash includes all messages up through the
> server CertificateVerify message, but not including any
>
On Mon, Dec 21, 2015 at 6:33 PM, Dave Garrett
wrote:
> On Monday, December 21, 2015 09:25:44 pm Christian Huitema wrote:
> > > I was just going over this text today and realized it's kind of
> confusing
> > > (and the whole "handshake_hash" abstraction is starting to be less
> useful
> > > in lig
On Wed, Dec 23, 2015 at 2:19 PM, Christian Huitema
wrote:
> In the current 1.3 draft, section 6.3.4.3 specifies the content of the
> Finished message. It contains this specification for key computation:
>
> client_finished_key =
> HKDF-Expand-Label(BaseKey, "client finished", "", L)
>
> serve
On Thu, Dec 24, 2015 at 3:40 PM, Christian Huitema
wrote:
> On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote:
> >
> > On 22 December 2015 at 13:25, Christian Huitema
> > wrote:
> > >> Unless I'm confused (which is possible given the time of night),
> > >> the intention, as you say, is
On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett
wrote:
> On Thursday, December 24, 2015 03:40:26 pm Christian Huitema wrote:
> > On Monday, December 21, 2015 6:30 PM, Martin Thomson wrote:
> > > On 22 December 2015 at 13:25, Christian Huitema >
> > > wrote:
> > > >> Unless I'm confused (which is p
On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett
wrote:
> On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote:
> > On Thu, Dec 24, 2015 at 4:26 PM, Dave Garrett
> > wrote:
> > > Do we have anything that protects against an intermediary stripping
> 0RTT
> &g
On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett
wrote:
> On Thursday, December 24, 2015 05:14:17 pm Eric Rescorla wrote:
> > On Thu, Dec 24, 2015 at 5:01 PM, Dave Garrett
> > wrote:
> > > On Thursday, December 24, 2015 04:48:58 pm Eric Rescorla wrote:
> > > > O
On Fri, Dec 25, 2015 at 3:04 AM, Ilari Liusvaara
wrote:
> On Thu, Dec 24, 2015 at 08:08:25PM -0500, Eric Rescorla wrote:
> > On Thu, Dec 24, 2015 at 5:48 PM, Dave Garrett
> > wrote:
> > >
> > > This last bit stops this, yes. I would prefer the spec say this ve
On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema
wrote:
> On Saturday, December 26, 2015 9:08 PM, Dave Garrett wrote:
> > On Thursday, December 24, 2015 08:08:25 pm Eric Rescorla wrote:
> > > Well, this is a general requirement any time the record MAC is bad:
> >
Folks,
In the spirit of making a useful checkpoint, I just posted the latest
version of the
editor's draft as draft-11. Here's the major changes:
- Port the CFRG curves & signatures work from RFC4492bis.
- Remove sequence number and version from additional_data, which
is now empty.
- Reorder
Scott, Henrick,
Are you persuaded by Watson's analysis?
Thanks,
-Ekr
On Mon, Dec 21, 2015 at 7:41 AM, Hubert Kario wrote:
> On Tuesday 15 December 2015 20:01:58 Bill Frantz wrote:
> > So we have to trade off the risks of too much data vs. the risks
> > of a complex rekey protocol vs. the ri
On Mon, Dec 28, 2015 at 3:08 PM, Florian Weimer wrote:
> On 12/21/2015 01:41 PM, Hubert Kario wrote:
>
> > if the rekey doesn't allow the application to change authentication
> > tokens (as it now stands), then rekey is much more secure than
> > renegotiation was in TLS <= 1.2
>
> You still have
On Mon, Dec 28, 2015 at 3:33 PM, Florian Weimer wrote:
> On 12/28/2015 09:11 PM, Eric Rescorla wrote:
>
> >> You still have the added complexity that during rekey, you need to
> >> temporarily switch from mere sending or receiving to at least
> >> half-duplex int
;
>
> Sent from my BlackBerry 10 smartphone on the Verizon Wireless 4G LTE network.
> *From: *Eric Rescorla
> *Sent: *Monday, December 28, 2015 15:37
> *To: *Florian Weimer
> *Cc: *tls@ietf.org
> *Subject: *Re: [TLS] Data volume limits
>
>
>
> On Mon, Dec 28, 2015 at 3:
On Mon, Dec 28, 2015 at 4:49 PM, Ilari Liusvaara
wrote:
> On Mon, Dec 28, 2015 at 06:46:02AM -0500, Eric Rescorla wrote:
> > On Sun, Dec 27, 2015 at 11:55 PM, Christian Huitema <
> huit...@microsoft.com>
> > wrote:
> >
> > > For DTLS, we have to consider th
On Tue, Dec 29, 2015 at 2:10 PM, Brian Smith wrote:
> Ilari Liusvaara wrote:
>
>> OTOH, you can't drop an attacker knowing older key without doing
>> new key exchange.
>>
>
> I think it would be very unfortunate to have the complexity of key update
> (the new keys are derived from the old keys)
is. The single use of
> "rekey" in the doc should probably be changed to "key update" if we keep
> things as-is, then.
Maybe. I don't find this taxonomy particularly evocative.
> On Tuesday, December 29, 2015 02:33:38 pm Eric Rescorla wrote:
> > Note: the key
On Wed, Dec 30, 2015 at 7:23 PM, Watson Ladd wrote:
>
> On Dec 30, 2015 7:08 PM, "Ilari Liusvaara"
> wrote:
> >
> > On Thu, Dec 31, 2015 at 09:55:10AM +1100, Martin Thomson wrote:
> > > On 30 December 2015 at 22:16, Ilari Liusvaara <
> ilariliusva...@welho.com> wrote:
> > > >> Would it make sens
I'm finding myself a bit unclear on the scenario people are concerned about.
It seems like there are two potential cases:
1. You have an implementation which already does some of the algorithms
we know are susceptible to THS-type attacks.
2. You have an implementation which only does the CFRG cur
On Thu, Dec 31, 2015 at 9:43 AM, Adam Langley
wrote:
> On Wed, Dec 30, 2015 at 7:40 PM, Brian Smith wrote:
> > When you say "the plan," whose plan are you referring to? If you read
> that
> > whole thread, there was a lot of well-founded opposition to that plan.
> And,
> > that plan was never ca
On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara
wrote:
> On Fri, Jan 01, 2016 at 06:22:00AM +1100, Martin Thomson wrote:
> > On 31 December 2015 at 17:54, Ilari Liusvaara
> wrote:
> > > Zero checks can already be unit-tested/interop-tested just as well.
> >
> >
> > What ekr said applies, but a
On Thu, Dec 31, 2015 at 12:49 PM, Ilari Liusvaara
wrote:
> On Thu, Dec 31, 2015 at 12:23:50PM -0800, Eric Rescorla wrote:
> > On Thu, Dec 31, 2015 at 12:20 PM, Ilari Liusvaara <
> ilariliusva...@welho.com>
> > wrote:
> >
> > 2. Implementations which only do ne
On Fri, Jan 1, 2016 at 11:00 AM, James Cloos wrote:
> [Msg for followup picked at random from this thread -JimC]
>
> One thing we should remember on this thread is that it does not only
> apply to aes and its' 128-bit block size.
>
> Because TLS chose to create a NotQuiteChaCha rather than use Ch
On Fri, Jan 1, 2016 at 4:42 PM, James Cloos wrote:
> >>>>> "ER" == Eric Rescorla writes:
>
> ER> Can you elaborate on this point a bit? I haven't been focusing on
> ER> ChaCha, but we're not quite done with ChaCha yet, so if changes are
>
On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario wrote:
> On Thursday 24 December 2015 01:04:59 Christian Huitema wrote:
> > On Wednesday, December 23, 2015 3:05 PM, Eric Rescorla wrote:
> > >> Similarly, in the HKDF-Expand-Label, do we assume a final null byte
> > >&
On Mon, Jan 4, 2016 at 9:58 AM, Hubert Kario wrote:
> On Monday 04 January 2016 09:44:57 Eric Rescorla wrote:
> > On Mon, Jan 4, 2016 at 9:22 AM, Hubert Kario
> wrote:
> > > On Thursday 24 December 2015 01:04:59 Christian Huitema wrote:
> > > > On Wednesday
On Mon, Jan 4, 2016 at 4:11 PM, Martin Thomson
wrote:
> On 5 January 2016 at 05:03, Eric Rescorla wrote:
> > Ask and ye shall receive:
> http://tlswg.github.io/tls13-spec/#digital-signing
> >
> > "Following that padding is a context string used to disambiguate
&
On Tue, Jan 12, 2016 at 9:17 AM, Ilari Liusvaara
wrote:
>
> > - Drop 99% of all cipher suites, leaving one traditional one (DHE +
> AES-CBC +
> > HMAC-SHA2 + RSA-SHA2/PSK for auth) and one ECC one (ECDHE + AES-GCM +
> HMAC-
> > SHA2 + ECDSA-SHA2/PSK for auth) as must's (with a strong preferenc
On Tue, Jan 12, 2016 at 10:06 AM, Dave Garrett
wrote:
> On Tuesday, January 12, 2016 12:51:28 pm Peter Bowen wrote:
> > On Tue, Jan 12, 2016 at 9:27 AM, Peter Bowen wrote:
> > > - No TLS_ECDHE_PSK_WITH_AES_128_GCM_SHA256 cipher suite allocated
> > > (BoringSSL has an implementation using cipher
On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote:
> On Tue, Jan 12, 2016 at 11:39 AM, Dave Garrett
> wrote:
>
>> On Tuesday, January 12, 2016 02:27:02 pm Bill Cox wrote:
>>
>> Personally, I hope this new version of TLS, save for possibly some minor
>> update & extensions, is the final version. I
On Tue, Jan 12, 2016 at 12:18 PM, Tony Arcieri wrote:
> On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox wrote:
>
>> I wish that were the plan (to upgrade QUIC crypto and eventually make
>> that the new crypto platform). If I am not mistaken, QUICK crypto is going
>> to be archived, TLS 1.3 will repl
On Tue, Jan 12, 2016 at 12:33 PM, Dave Garrett
wrote:
> On Tuesday, January 12, 2016 03:18:11 pm Eric Rescorla wrote:
> > On Tue, Jan 12, 2016 at 12:12 PM, Bill Cox
> wrote:
> > > I wish that were the plan (to upgrade QUIC crypto and eventually make
> that
> > >
On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier
wrote:
> Hi,
>
> TLS 1.2 RFC says that a a client certificate MUST be compatible the
> parameters specified in the Certificate Request: key type,
> hash/signature algorithm and CA.
> If a client does not have such a compatible cert, it MUST send an
On Tue, Jan 12, 2016 at 1:30 PM, Fabrice Gautier
wrote:
> On Tue, Jan 12, 2016 at 1:13 PM, Eric Rescorla wrote:
> >
> >
> > On Tue, Jan 12, 2016 at 1:07 PM, Fabrice Gautier <
> fabrice.gaut...@gmail.com>
> > wrote:
> >>
> >> Hi,
> >
On Tue, Jan 12, 2016 at 4:13 PM, Fabrice Gautier
wrote:
>
> > With TLS 1.2, where the server does send a supported_signature_algorithms
> > list, clients that use signatures other than those listed should
> > expect to run into servers that reject this with a fatal alert.
> > The server's TLS sta
I concur.
-Ekr
On Thu, Jan 14, 2016 at 7:14 AM, Simon Josefsson
wrote:
> Allocating a code point for X25519 could be done and is long overdue
> (first draft September 2013). X448 is also stable. Code points for
> Ed25519 and Ed448 is more problematic since TLS authentication has
> historical
On Fri, Jan 15, 2016 at 5:19 PM, David Benjamin
wrote:
> On Fri, Jan 15, 2016 at 8:07 PM Dave Garrett
> wrote:
>
>> On Friday, January 15, 2016 03:45:34 pm David Benjamin wrote:
>> > This is a proposal for revising SignatureAlgorithm/HashAlgorithm. In TLS
>> > 1.2, signature algorithms are sprea
On Fri, Jan 22, 2016 at 7:50 AM, =JeffH
wrote:
> wrt https://tools.ietf.org/html/draft-ietf-tls-tls13-11#section-4.3
>
> if we have..
>
> opaque foo<0..2^16-1>;
>
> ..with a floor length of zero, thus with an instantiation of foo of zero
> length, we actually will have in terms of encoded bytes
On Tue, Jan 26, 2016 at 6:02 PM, David Benjamin
wrote:
> Instead of putting 0-RTT data in a ClientHello extension, the current
> draft has the client send extra records in the first flight, right? (I see
> an early_data extension, but it seems only be an indicator. There's also
> mention of requi
Hi folks,
TL;DR.
I propose that we should not change keys between the handshake
and application traffic keys.
DETAILS
As we try to finalize the drafts and implementations are starting to
emerge, it's worth looking for opportunities to simplify. This is the
first of several messages suggesting are
On Thu, Feb 18, 2016 at 7:32 AM, Wan-Teh Chang wrote:
> On Wed, Feb 17, 2016 at 7:49 PM, Eric Rescorla wrote:
> >
> > TL;DR.
> > I propose that we should not change keys between the handshake
> > and application traffic keys.
>
> Hi Eric,
>
> I'
Hi folks,
TL;DR.
Let's simplify the key schedule.
DETAILS
This is the second in a series of proposed simplifications to TLS 1.3
based on implementation experience and analysis once the protocol
starts to harden. The following suggestion comes out of conversations
with Richard Barnes, Karthik Bh
TL;DR.
Should we remove the semi-static DHE 0-RTT mode and just leave
the PSK and PSK-DHE 0-RTT modes?
DETAIL
This is the last in the series of messages about changes to consider.
TLS 1.3 currently supports two 0-RTT modes:
- A semi-static Diffie-Hellman mode in which the server provides
a lo
as DH-based with authentication occurring through the server
> Finished MAC (with a key derived from SS which can take the values of g^xs,
> g^xy or PSK). That is common to *all* modes, including 0-RTT and PSK which
> do
> not build on signatures. This is how the protocol was built origina
On Fri, Feb 19, 2016 at 3:58 AM, Ilari Liusvaara
wrote:
> On Fri, Feb 19, 2016 at 10:04:38AM +0100, Karthikeyan Bhargavan wrote:
>
> > Regardless of whether we make this change though, I think it would be
> > useful for the TLS 1.3 RFC to clearly limit the scope of various keys
> > generated by t
+ TLS WG
On Fri, Feb 19, 2016 at 8:46 AM, Eric Rescorla wrote:
>
> On Fri, Feb 19, 2016 at 8:01 AM, Salz, Rich wrote:
>
>> I greatly prefer one way to do things. (Python not perl, if you will :)
>>
>> On the other hand, there is an elegance about using a single
&
On Fri, Feb 19, 2016 at 11:25 AM, Watson Ladd wrote:
> Cf 6.3.4.2. Certificate Verify with 6.3.5.1. New Session Ticket Message
>
> and we see that client certificate verification is allowed for some
> PSK exchanges and not others, and that the PSK exchanges used in
> resumption are ones where it
On Fri, Feb 19, 2016 at 3:08 PM, Dave Garrett
wrote:
> On Friday, February 19, 2016 12:57:04 am Bill Cox wrote:
> > Having two different modes to achieve basically the same
> > thing in TLS 1.3 is a bad idea.
>
> On Friday, February 19, 2016 10:01:31 am Salz, Rich wrote:
> > I greatly prefer one
On Fri, Feb 19, 2016 at 4:15 PM, Dave Garrett
wrote:
> On Friday, February 19, 2016 05:24:25 pm Eric Rescorla wrote:
> > My impression is exactly the opposite. All the infrastructure to
> PSK-resumption and
> > hence PSK-0RTT is already in place for TLS 1.2. And of course
>
I don't believe that this is going to work very well, since it is a fairly
large burden for referring
servers to refresh their state.
-Ekr
On Fri, Feb 19, 2016 at 5:00 PM, Dave Garrett
wrote:
> On Friday, February 19, 2016 07:47:31 pm Martin Thomson wrote:
> > This really only helps on the fir
Kenny,
Would you have a problem with doing as Karthik suggests and generating
separate traffic and handshake keys but at the same time?
-Ekr
On Sat, Feb 20, 2016 at 11:58 AM, Paterson, Kenny wrote:
> Hi
>
> My 2c below...
>
> On 20/02/2016 18:53, "TLS on behalf of Cedric Fournet"
> wrote:
>
+1
On Sun, Feb 21, 2016 at 11:31 AM, Martin Thomson
wrote:
> I'm sitting here in TRON listening to Karthik describe all the various
> ways in which client authentication in 0-RTT is bad. I'm particularly
> sympathetic to the perpetual impersonation attack that arises when the
> client's ephemer
This was discussed at the TLS interim and the argument against was that
there was limited demand for the post-handshake mode and that people
wanted to have a mode they were very comfortable with as the "main"
thing. Of course, it may be time to revisit that decision.
-Ekr
On Sun, Feb 21, 2016 at
Correct.
-Ekr
On Sun, Feb 21, 2016 at 11:41 AM, Cedric Fournet
wrote:
> Agreed. For what it is worth, 0-RTT with PSK would still provide implicit
> client authentication.
>
>
>
>
>
> *From:* TLS [mailto:tls-boun...@ietf.org] *On Behalf Of *Eric Rescorla
> *Sent:* 2
On Sun, Feb 21, 2016 at 12:05 PM, Martin Thomson
wrote:
> On 21 February 2016 at 12:01, Adam Langley wrote:
> > The token-binding(*) folks care about authenticating 0-RTT requests,
> > although they are currently working at the application-layer[1] and so
> > would be recreating 0-RTT client aut
On Wed, Feb 24, 2016 at 3:11 PM, Watson Ladd wrote:
> On Tue, Feb 23, 2016 at 7:39 PM, Hugo Krawczyk
> wrote:
> >
> >
> > On Tue, Feb 23, 2016 at 8:57 PM, Dave Garrett
> > wrote:
> >>
> >> On Tuesday, February 23, 2016 02:03:53 pm Martin Thomson wrote:
> >> > I propose that we remove DH-based 0
On Thu, Feb 25, 2016 at 9:55 PM, Antoine Delignat-Lavaud <
anto...@delignat-lavaud.fr> wrote:
> Le 2016-02-25 12:29, m...@sap.com a écrit :
>
>> Karthikeyan Bhargavan wrote:
>>
>>>
>>> Yes Hugo, you?re right that when there is no client auth,
>>> the situation is less problematic.
>>>
>>
>> I'm no
On Fri, Feb 26, 2016 at 4:24 AM, Ilari Liusvaara
wrote:
> On Fri, Feb 26, 2016 at 01:27:45AM -0800, Judson Wilson wrote:
> > Hello folks,
> >
> > How this helps: In the current draft, an endpoint that sends a KeyUpdate
> > message and later receives a KeyUpdate message cannot know whether the
> >
On Wed, Jul 8, 2020 at 3:59 AM Benjamin Kaduk wrote:
> Hi all,
>
> There's an interesting note in draft-ietf-nfsv4-rpc-tls-08 (currently
> in IESG Evaluation):
>
>The protocol convention specified in the current document assumes
>there can be no more than one concurrent TLS session per TC
On Tue, Jul 28, 2020 at 12:26 AM Martin Thomson wrote:
> The following text from Section 5.3 is deeply problematic:
>
>A decryption policy decision MAY be made based on the server
>certificate or other trustworthy parameters. To verify possession of
>private keys that are associated
On Wed, Jul 29, 2020 at 4:27 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 29/07/2020 23:46, Eric Wang (ejwang) wrote:
> > It was the motivation of this draft to help reduce/prevent
> > non-compliance, as mentioned earlier.
> TLS MITM products, by design, do not comply with the TLS
> protocol, which
On Wed, Jul 29, 2020 at 5:06 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 30/07/2020 00:56, Eric Rescorla wrote:
> > What text in TLS do you believe terminating proxies (in either direction)
> > do not conform to?
>
> I gtend to start with the abstract: "TLS all
Hi folks,
I've just posted draft-rescorla-tls-rfc8446-bis-00.
This document does two things:
1. It rolls up all the various errata that have been filed for
RFC 8446. Some of these have created some reader confusion
and so hopefully this will help.
2. It renames the "master" secrets to "ma
On Tue, Aug 11, 2020 at 12:10 PM Stephen Farrell
wrote:
>
> I count 32 messages like this, relating to the ESNI draft,
> as github discussion, in the last 24 hours.
>
> Some of those do not need to be reflected to the TLS WG
> list, but I suspect others do, and before discussion
> resolves into a
On Tue, Aug 11, 2020 at 1:24 PM Stephen Farrell
wrote:
> On 11/08/2020 20:37, Eric Rescorla wrote:
> > I note that draft-ietf-git-github explicitly permits discussion on the
> > issues,
>
> Well, sure. I know that some people like that, and
> it does have benefits. But
On Thu, Aug 20, 2020 at 7:01 AM Roelof DuToit wrote:
> As co-author I am not a proponent of passive TLS inspection - not least
> because of the ossification implications. It cannot be labeled as
> ineffective though (see further comments below), even if the document
> strongly hints at not using
Unsurprisingly, I support adoption. My hope here is that we can quickly
flush out remaining issues that could cause confusion and get this to the
IESG.
-Ekr
On Wed, Sep 2, 2020 at 9:20 AM Salz, Rich
wrote:
> I support this and will help work on it.
>
> _
On Wed, Sep 2, 2020 at 12:52 PM David Schinazi
wrote:
> I support adoption and am willing to help review.
>
> In case anyone else finds it helpful, here's a diff from RFC 8446:
>
> https://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=rfc8446&url2=draft-rescorla-tls-rfc8446-bis-00
>
Thanks. I a
On Thu, Sep 10, 2020 at 11:52 AM Mike Bishop wrote:
> This is primarily an active attack, but not purely so. Clearly the MITM
> is an active attacker, but there are situations in QUIC (and DTLS, I
> presume) where a ClientHello gets retransmitted. Depending on server
> infrastructure, the clien
On Thu, Sep 10, 2020 at 2:21 PM Mike Bishop wrote:
> Certainly it’s better for the server if it can be consistent, especially
> if it expects multi-packet first flights. If the same back-end sees both,
> it can discard the second, and that’s what I’d expect most of the time.
> But here’s what I
I tend to agree with Ben Schwartz on this. I have two
concerns about this draft:
1. It seems likely that it will lead to ossification. While
it is true that devices can in theory update their MUD
descriptions, as a practical matter expecting middleboxes
to enforce certain properties of the TLS han
Taking a step back from details, ISTM that the whole design of this
document is antithetical to extensibility:
TLS is a protocol with a number of extension points. What this document
does is allow an endpoint to restrict its use of a certain set of extension
points. However, the language provided h
On Fri, Sep 18, 2020 at 3:12 PM Michael Richardson
wrote:
>
> ekr> Taking a step back from details, ISTM that the whole design of this
> ekr> document is antithetical to extensibility:
>
> I agree. It was my first reaction as well.
> I then had another thought: there are dozens of entities out t
On Sat, Sep 19, 2020 at 3:07 PM Michael Richardson
wrote:
>
> Eric Rescorla wrote:
> ekr> As a thought example, consider a hypothetical TLS 1.4 which
> decided to
> ekr> adopt QUIC-style obfuscation of the CH and SH, putting the
> obfuscated
> ek
On Sat, Sep 12, 2020 at 11:41 AM Christopher Patton wrote:
> I agree with Christian. The reason to use the ServerHello.random trick is
> to make real ECH connections look like connections in which the client
> sends a dummy ECH extension to a non-ECH server. In particular, this design
> pattern i
On Wed, Sep 23, 2020 at 2:51 AM tirumal reddy wrote:
> Hi Ben,
>
> Please see inline
>
> On Tue, 22 Sep 2020 at 20:45, Ben Schwartz wrote:
>
>> I'm not able to understand the new text in Section 6. Are you saying
>> that clients MUST include all the listed extensions/features, but MAY also
>> i
I am completely indifferent on Updates versus Obsoletes (Indeed, this
discussion seems like more support for my argument that we should get rid
of the
distinction). With that said, I believe that this analysis is broadly
correct.
To recap the situation as I understand it:
TLS always provided anti-
Hi folks,
cTLS uses a bespoke varint format. Now that QUIC is nearly done, I propose
adopting their varint format.
https://github.com/tlswg/draft-ietf-tls-ctls/pull/28
Any objections?
-Ekr
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/
ambiguous way to encode a number.
>
> On Tue, Oct 6, 2020 at 07:35 Eric Rescorla wrote:
>
>> Hi folks,
>>
>> cTLS uses a bespoke varint format. Now that QUIC is nearly done, I
>> propose adopting their varint format.
>>
>> https://gith
odings everywhere
> > else).
> > It would be nice to have an unambiguous way to encode a number.
> >
> > On Tue, Oct 6, 2020 at 07:35 Eric Rescorla wrote:
> > > Hi folks,
> > >
> > > cTLS uses a bespoke varint format. Now that QUIC is nearly
I don't have a strong opinion on whether to require a minimal encoding, but
if we're not going to use QUIC's encoding as-is, then I would rather stick
with the existing scheme, which has twice as large a range for the 1 byte
encoding and is thus more compact for a range of common cases.
-Ekr
On
I would like to make several points here:
- In terms of operational practice, in order for a server to
function correctly, the CID must either be fixed-length for all
clients that might need to be demuxed *or*
self-describing. Otherwise, the server will not be able to determine
the correct CID. I
On Wed, Oct 21, 2020 at 3:51 PM Christopher Wood
wrote:
> RFC 8874 describes several different methods for using GitHub, ranging
> from the lightweight "document management mode" [1] to more heavyweight
> "issue discussion mode" [2]. Most TLS documents are hosted and worked on in
> GitHub, though
On Fri, Oct 23, 2020 at 7:13 PM Benjamin Kaduk wrote:
> Hi Ekr,
>
> Thanks for chiming in.
>
> On Thu, Oct 15, 2020 at 08:59:43AM -0700, Eric Rescorla wrote:
> >
> > - I agree with Ben that the current construction has some awkward
> > properties and that prefix
On Mon, Oct 26, 2020 at 6:00 PM Benjamin Kaduk wrote:
> On Mon, Oct 26, 2020 at 05:38:33PM -0700, Eric Rescorla wrote:
> > On Fri, Oct 23, 2020 at 7:13 PM Benjamin Kaduk wrote:
> >
> > > Hi Ekr,
> > >
> > > Thanks for chiming in.
> > >
&
On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 27/10/2020 22:28, Mark Nottingham wrote:
> > Stephen,
> >
> > I don't think what you're complaining about can be attributed to
> > GitHub. Tools are just tools, how they're used is what's relevant
> > (i.e., this could just a
On Tue, Oct 27, 2020 at 4:20 PM Stephen Farrell
wrote:
>
> Hiya,
>
> On 27/10/2020 23:06, Eric Rescorla wrote:
> > On Tue, Oct 27, 2020 at 4:00 PM Stephen Farrell
> > wrote:
> >
> >>
> >> Hiya,
> >>
> >> On 27/10/2020 22:28, Ma
Ben,
Thanks for your comments. I will get on these ASAP.
-Ekr
On Fri, Nov 13, 2020 at 3:52 PM Benjamin Kaduk wrote:
> Hi all,
>
> Sorry this took longer than planned to get to -- running my pubreq queue in
> order took longer than expected.
>
> I made a pull request with editorial/nit-level s
cient, let's
> keep it as is, otherwise let's change it to the QUIC format (or some other
> change to increase the max value). I do like that the existing scheme,
> compared to QUIC varints, is more efficient for values 64-127 and just as
> efficient for the rest.
>
>
e encode it
> open to work in the group. There are various possible designs and none of
> them is rocket science.
>
Yep. If it looks like we are getting consensus I will work up a proposal.
-Ekr
>
> Ciao
>
> Hannes
>
>
>
> *From:* TLS *On Behalf Of * Eric Rescor
Argh, Good catch. I'll revise the proposal in light of this point.
-Ekr
On Tue, Nov 17, 2020 at 1:09 AM Achim Kraus wrote:
> Hi Ben,
>
> Am 17.11.20 um 07:07 schrieb Benjamin Kaduk:
> > On Fri, Oct 30, 2020 at 01:28:12PM +0100, Achim Kraus wrote:
> >> Hi Ekr,
> >>
> >>> As for EtM
> >>>
> >>>
Keith,
Thanks for your note. Most of the general points you raise here were
discussed
when the TLS WG decided to move forward with this draft [0], though
perhaps some of that is not reflected in the text. Of course that
doesn't make this points invalid, so I'll try to summarize my
view of the rati
d me
(perhaps due to unclear writing on my part).
On Fri, Nov 27, 2020 at 7:39 PM Keith Moore
wrote:
> On 11/27/20 9:53 PM, Eric Rescorla wrote:
> > This
> > would be true in any case, but is doubly true in the case of COMSEC
> > protocols: What we want is to be able to
Well, I think our respective positions are clear, so I'll just limit myself
to one point.
On Fri, Nov 27, 2020 at 8:43 PM Keith Moore
wrote:
> >
> >
> > > > I'm not sure what clients you're talking about, but for the clients
> > > > I am aware of, this would be somewhere between a broken experie
On Sun, Nov 29, 2020 at 10:36 PM Olle E. Johansson wrote:
>
>
> > On 30 Nov 2020, at 01:51, Watson Ladd wrote:
> >
> > Dear TLS WG,
> >
> > I think RFC 7627 should update 5056, 5705, and maybe a few more.
> >
> > I noticed these omissions when looking at the kitten draft to use TLS
> > 1.3 expor
On Mon, Nov 30, 2020 at 5:12 AM Olle E. Johansson wrote:
>
>
> On 30 Nov 2020, at 14:08, Eric Rescorla wrote:
>
>
>
> On Sun, Nov 29, 2020 at 10:36 PM Olle E. Johansson wrote:
>
>>
>>
>> > On 30 Nov 2020, at 01:51, Watson Ladd wrote:
>> &g
201 - 300 of 1635 matches
Mail list logo
