Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

Questions for PR [1]: * Regarding this text: The client MUST NOT use the server-provided retry keys until the handshake completes successfully. On success, it MUST NOT overwrite the DNS-provided keys with the retry keys. It MUST use the retry keys at most once and continue offering

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

To be clear, the intent of the PR is definitely not to extrapolate any signals about the current network. That way lies attacks. It's only ever that one origin. If it turns out that all origins securely disable ESNI, then that's what happens, but they each have to do so individually. (A bit late

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

Perhaps a better way to phrase it is that a server which successfully authenticates as the public_name but does not support ESNI has securely disabled ESNI for that origin, subject to the same rules as if it had supplied a new ESNI key (i.e. use for now, but don't persist). Leave as an

Re: [TLS] Version pinning and indicating the signing algorithm in draft-ietf-tls-subcerts-02

Watson put up a PR https://github.com/tlswg/tls-subcerts/pull/21. I'm going to merge it tomorrow if there's no other feedback on it. [https://avatars3.githubusercontent.com/u/1123811?s=400=4] Remove protocol from the structure by wbl · Pull Request

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

Hiya, Various bits'n'pieces below... On 13/02/2019 23:55, David Benjamin wrote: > Thanks for the comments! Responses inline. > > On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell > wrote: > >> >> Hiya, >> >> On 13/02/2019 22:15, Christopher Wood wrote: >>> >>> >>> [1]

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

Thanks for the comments! Responses inline. On Wed, Feb 13, 2019 at 5:00 PM Stephen Farrell wrote: > > Hiya, > > On 13/02/2019 22:15, Christopher Wood wrote: > > > > > > [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 > > I just re-read that. I've a question: why tie the version >

Re: [TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

Hiya, On 13/02/2019 22:15, Christopher Wood wrote: > > > [1] https://github.com/tlswg/draft-ietf-tls-esni/pull/124 I just re-read that. I've a question: why tie the version change to this PR and not the I-D rev? I'd prefer if we make the change to 0xff02 when -03 is published. (I don't care

[TLS] ESNI PRs #124 and #125: Improving ESNI Robustness and GREASE

Hi folks, PRs [1] and [2] need a little more review before we merge since they’re non-trivial changes. Please have a look and let the list know if you have objections with the contents therein. Otherwise, we will merge them by the end of the next week. Thanks! Chris (no hat) [1]

Re: [TLS] Server validation of a second ClientHello

On Wed, Feb 13, 2019 at 11:37 AM Hubert Kario wrote: > On Wednesday, 13 February 2019 20:01:10 CET Eric Rescorla wrote: > > On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote: > > > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote: > > > > On Wed, Feb 13, 2019 at 7:39 AM Hubert

Re: [TLS] Server validation of a second ClientHello

On Wednesday, 13 February 2019 20:01:10 CET Eric Rescorla wrote: > On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote: > > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote: > > > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote: > > > > On Wednesday, 13 February 2019 15:39:03

Re: [TLS] Server validation of a second ClientHello

On Wed, Feb 13, 2019 at 10:23 AM Hubert Kario wrote: > On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote: > > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote: > > > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > > > I'n not sure I understand your question,

Re: [TLS] Server validation of a second ClientHello

On Wednesday, 13 February 2019 17:31:52 CET Eric Rescorla wrote: > On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote: > > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > > I'n not sure I understand your question, but I'll try to answer what I > > > think it says. > > > > >

[TLS] New Liaison Statement, "LS on SG17 work item X.ibc-iot: Security framework for using Identity Based Cryptography for IoT services over telecom networks"

Title: LS on SG17 work item X.ibc-iot: Security framework for using Identity Based Cryptography for IoT services over telecom networks Submission Date: 2019-02-13 URL of the IETF Web page: https://datatracker.ietf.org/liaison/1629/ Please reply by 2019-06-30 From: Xiaoya Yang To: Christopher

Re: [TLS] Server validation of a second ClientHello

On Wed, Feb 13, 2019 at 7:39 AM Hubert Kario wrote: > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote: > > > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote: > > > > I concur with what I take to be MT's

Re: [TLS] Server validation of a second ClientHello

On Wed, Feb 13, 2019 at 04:39:49PM +0100, Hubert Kario wrote: > On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > > > To my knowledge, there was never a WG discussion about this exact question, > > so we only have the spec to guide us. Were we pre-publication I would have > >

Re: [TLS] Server validation of a second ClientHello

On Wednesday, 13 February 2019 15:39:03 CET Eric Rescorla wrote: > On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote: > > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote: > > > I concur with what I take to be MT's position here: > > > > > > 1. The client is clearly prohibited

Re: [TLS] Server validation of a second ClientHello

On Mon, Feb 11, 2019 at 10:43:39AM +1100, Martin Thomson wrote: > On Fri, Feb 8, 2019, at 23:53, Hubert Kario wrote: > > > > If we require or allow checking - and I think that we should definitely > > > allow a check - the details of the conditions under which a check might > > > fail aren't

Re: [TLS] Server validation of a second ClientHello

On Wed, Feb 13, 2019 at 06:39:03AM -0800, Eric Rescorla wrote: > On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote: > > > you are not suggesting that which value will be used (from first or second > > CH), or if the connection will be aborted, to be implementation dependant > > *by design* , do

Re: [TLS] Server validation of a second ClientHello

On Wed, Feb 13, 2019 at 4:12 AM Hubert Kario wrote: > On Wednesday, 13 February 2019 01:31:41 CET Eric Rescorla wrote: > > I concur with what I take to be MT's position here: > > > > 1. The client is clearly prohibited from changing most elements of the CH > > (except for listed exceptions). > >

Re: [TLS] SK filtering on SNI, blocking ESNI

On Wed, Feb 13, 2019 at 1:32 PM Joseph Lorenzo Hall wrote: > It appears South Korea has started censoring traffic across all ISPs based > on SNI [1], [2]. Nick points out that they seem to be blocking ESNI > entirely [3]. > > [1]: https://bugzil.la/1494901#c3 > [2]:

[TLS] SK filtering on SNI, blocking ESNI

It appears South Korea has started censoring traffic across all ISPs based on SNI [1], [2]. Nick points out that they seem to be blocking ESNI entirely [3]. [1]: https://bugzil.la/1494901#c3 [2]: https://news.joins.com/article/23363557 [3]: