On 22 August 2015 at 19:28, Dave Garrett wrote:
> Toggling solves the undesired bandwidth use concern stated by Tom by making
> it fully optional on both sides. The even simpler route of just having to
> check if there's bytes in the encrypted fragment other than the payload would
> avoid a lit
On 15 September 2015 at 20:42, Tony Arcieri wrote:
> +1 for removing anonymous DH
+1.
Even for the anonymous use cases I like having a long-term key around
for people to optionally remember. (I realize we're not requiring
that.)
-tom
___
TLS mailing
On 5 December 2015 at 12:32, Eric Rescorla wrote:
> Subject: SNI Encryption Part XLVIII
A small concern that probably is "No, that can't happen", but I would
want to be sure that a normal (non-encrypted SNI) ClientHello would be
unable to be wrapped in a new ClientHello to a gateway by a MITM
(wi
On 5 December 2015 at 21:31, Eric Rescorla wrote:
>
>
> On Sat, Dec 5, 2015 at 7:06 PM, Tom Ritter wrote:
>>
>> On 5 December 2015 at 12:32, Eric Rescorla wrote:
>> > Subject: SNI Encryption Part XLVIII
>>
>> A small concern that probably is "No
On 13 November 2017 at 07:28, Bret Jordan wrote:
> All,
>
> We had a great turnout tonight for the encrypted SNI hangout session.
> Everyone seemed open and willing to work together to understand the
> complexities that sit before us. Several interesting and important views
> were expressed, and I
On 15 May 2018 at 22:14, Viktor Dukhovni wrote:
> I therefore appeal to the readers who've so far stayed silent on this
> issue, to lend support to paving the way for a more broadly applicable
> downgrade-resistant protocol, by supporting the inclusion of a two byte
> field for that purpose.
Sorr
I was not at the interim, so this email comes without context of that
discussion. Apologies if this was exactly what the chairs didn't
want...
On Tue, 9 Oct 2018 at 00:10, Christopher Wood
wrote:
> - October 8 through October 19: Discuss the problem statement. In
> particular, if anyone feels the
On Tue, 26 Mar 2019 at 09:12, Yoav Nir wrote:
> Are we really worried that we’re going to have more than 255 optional
> features for TLS?
Probably not; but what about an optional feature that needs 3 bits? Is
it better to kick them off into 4 bytes?
-tom
___
On 16 March 2016 at 09:52, Colm MacCárthaigh wrote:
> At a minimum: could we agree that if a service/site is sensitive to privacy
> - it's reasonable for them to prefer AES-CBC; should they be penalized in
> SSL health analysis tools/reports for that configuration? it's not as
> flexible or useful
On 17 March 2016 at 21:09, Martin Thomson wrote:
> On 18 March 2016 at 12:37, Mike Hamburg wrote:
>> No. The goal should be to remove ciphers, not add new ones, unless we have
>> a really compelling reason.
>
> A necessary, but sufficient set of reasons might include:
>
> 1. thorough cryptanalys
On 8 October 2016 at 11:54, Eric Rescorla wrote:
> I could go either way on this. It seems like this pushes complexity from the
> client to the server.
>
> Consider the case of NST. Presently, a client which doesn't want resumption
> can just ignore NST,
> but in your proposed change, the server n
As a note, I didn't see anything in this draft (from a quick read)
that precludes any of DANE's Certificate Usage, Selector, or Matching
Type fields. If that's not the case, perhaps someone can correct me.
A client must not be able to force a server to perform lookups on
arbitrary domain nam
On Jul 17, 2017 6:06 AM, "Roland Dobbins" wrote:
On 16 Jul 2017, at 0:34, Daniel Kahn Gillmor wrote:
Strongly enough to support a proposal that would require this to be
> opt-in from both sides, with an explicit and verifiable exfiltration
> authority, so that no standard implementation of the p
If I remember correctly, the idea of enabling SNI encryption (and
0RTT) via DNS had been brought up very early on in the discussion.
draft-nygren-service-bindings was the first (only? major?) concrete
proposal.
In general, I think the feedback was "DNS gets filtered to only
A/CNAME records so freq
On 20 July 2017 at 01:53, Yoav Nir wrote:
>
> On 20 Jul 2017, at 8:01, Russ Housley wrote:
>
> Ted, if we use a new extension, then the server cannot include it unless the
> client offered it first. I am thinking of an approach where the server
> would include information needed by the decryptor
On 20 July 2017 at 10:07, Paul Turner wrote:
> It seems like that problem exists today with TLS 1.3. If a government is
> powerful enough to mandate key escrow, wouldn’t they also be power enough to
> mandate implementing static DH with TLS 1.3 (so that they key escrow is
> possible). In addition,
On 20 July 2017 at 10:29, Paul Turner wrote:
> Thanks for this clarification. I agree that anything is possible in both
> directions. Russ opened this discussion by asking about an alternative to
> static DH. In this model, I’ve assumed the client would need to explicitly
> opt-in by including an
On Aug 4, 2017 9:22 AM, "Daniel Kahn Gillmor" wrote:
On Fri 2017-08-04 08:50:33 -0400, Sean Turner wrote:
> At our IETF 99 session, there was support in the room to adopt
> draft-huitema-tls-sni-encryption [0]. We need to confirm this support
> on the list so please let the list know whether you
18 matches
Mail list logo
