IETF Logo Mail Archive

Re: [TLS] Connection ID Draft

Nikos Mavrogiannopoulos <nmav@redhat.com> Wed, 18 October 2017 08:13 UTC

Return-Path: <nmav@redhat.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C12B0132199 for <tls@ietfa.amsl.com>; Wed, 18 Oct 2017 01:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.42
X-Spam-Level:
X-Spam-Status: No, score=-1.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iWOGSPFT0ozr for <tls@ietfa.amsl.com>; Wed, 18 Oct 2017 01:13:08 -0700 (PDT)
Received: from mail-wm0-f51.google.com (mail-wm0-f51.google.com [74.125.82.51]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B8E913292F for <tls@ietf.org>; Wed, 18 Oct 2017 01:13:08 -0700 (PDT)
Received: by mail-wm0-f51.google.com with SMTP id l68so8440837wmd.5 for <tls@ietf.org>; Wed, 18 Oct 2017 01:13:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:date:in-reply-to :references:mime-version:content-transfer-encoding; bh=brC9kWp/QTPa9+whJ5zhb6zLli13cVV1RxERdg9KG4M=; b=sO98x3CVQP8kh7HXUIvzoQRydGU4CY5VLcPF0wCUu7ks47xSYPMREodPWYFOOYGgWe TytbZMIBlLbyWb8jP8MGkXEk8C+GMXs4cWYlZqUWLAKMXZpDv+IkEwlZHwc1SS3b0Xj9 RMDBtkEDjtZ9vbabmkJFj2IObRJ/U0gNsre7PvG79zWLNo35CmsrN5wwZ9kIX/87fazO hwuGYFBPhGDLbAThd7ODIe8pV5L7SLc97fLdZMl6rmNV+odcL2m9QqBPSE6UdK6Q75ez yWcfKDNxaCoCHnBByXhtUeTNXwkzzJz2Fifr5afrifkzkpZd8y7eZvAVK2pN2WB7G6ZI xiAA==
X-Gm-Message-State: AMCzsaVl8xE76zVB5trzwLm/PpYdTIJcL/ltgF2sB65a0mwPIF3sh6Dh GpA00kObN0UqCDKemPwCajoAKA==
X-Google-Smtp-Source: ABhQp+SJsC0vlCgRUrk567mRbof7Ph7VK+OpgqgylL89YQF9COT1py/MkJULtGcXluNOJIFHabhlOA==
X-Received: by 10.28.196.205 with SMTP id u196mr5255668wmf.120.1508314386661; Wed, 18 Oct 2017 01:13:06 -0700 (PDT)
Received: from dhcp-10-40-1-102.brq.redhat.com ([2a02:214d:8007:2600:527b:9dff:fe2b:1d57]) by smtp.gmail.com with ESMTPSA id u52sm20589038wrb.23.2017.10.18.01.13.05 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Oct 2017 01:13:05 -0700 (PDT)
Message-ID: <1508314383.2929.23.camel@redhat.com>
From: Nikos Mavrogiannopoulos <nmav@redhat.com>
To: "Fossati, Thomas (Nokia - GB/Cambridge, UK)" <thomas.fossati@nokia.com>, Eric Rescorla <ekr@rtfm.com>, "tls@ietf.org" <tls@ietf.org>
Date: Wed, 18 Oct 2017 10:13:03 +0200
In-Reply-To: <12771800-934C-4542-9F26-2E07B2C8D684@nokia.com>
References: <CABcZeBPXB6cOSztzDHtKSWUCJrgET+9cF_rAiiE8CYCUSY_uLA@mail.gmail.com> <1507875665.3178.19.camel@redhat.com> <12771800-934C-4542-9F26-2E07B2C8D684@nokia.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.24.6 (3.24.6-1.fc26)
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/WgucTpprUrs2Nn0e5-B8XlDnjxk>
Subject: Re: [TLS] Connection ID Draft
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 Oct 2017 08:13:10 -0000

On Wed, 2017-10-18 at 06:43 +0000, Fossati, Thomas (Nokia -
GB/Cambridge, UK) wrote:
> Hi Nikos,
> 
> On 13/10/2017, 07:21, "TLS on behalf of Nikos Mavrogiannopoulos" <tls
> -bounces@ietf.org on behalf of nmav@redhat.com> wrote:
> > Another worrying feature is that the client can make the server
> > send
> > up to 255 verbatim bytes on the wire of his choice. Why was this
> > feature added? Are there use cases related with it (intro doesn't
> > mention any), or it was only thought as a make it as generic as
> > possible approach? If it is the latter, I'd recommend to provide a
> > simple approach that covers the described use cases.
> > 
> > The same argument applies to the server being able to set such a
> > long
> > sequence of verbatim bytes to each of the client packets.
> 
> I'd like to get a better understanding of your concern here.
> Is it size?

I had in mind scenarios of using these bytes to make the peer of talk
another protocol with an unsuspecting party, or using the peer to
attack a middle box which parses packets, e.g, by attempting buffer
overflows to it.

regards,
Nikos

v2.23.0 | Report a Bug | By Email