IETF Logo Mail Archive

Re: [TLS] Alvaro Retana's No Objection on draft-ietf-tls-padding-02: (with COMMENT)

Eric Rescorla <ekr@rtfm.com> Tue, 01 September 2015 16:50 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 192AB1AD364 for <tls@ietfa.amsl.com>; Tue, 1 Sep 2015 09:50:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 QF_efnxJWQze for <tls@ietfa.amsl.com>; Tue, 1 Sep 2015 09:50:20 -0700 (PDT)
Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (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 0D06D1B4BE7 for <tls@ietf.org>; Tue, 1 Sep 2015 09:49:48 -0700 (PDT)
Received: by wicfx3 with SMTP id fx3so19140181wic.0 for <tls@ietf.org>; Tue, 01 Sep 2015 09:49:46 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=tJArCCwUc0zwh6VWe/kp8Yx3rLelipzNa87lxq5l1Ys=; b=YlU9IqP64BUMiiQ4p7Z3mWCI+mM+Pq1Mt5pVLFBhB37UCl86rdpp+CwLalYaffXg+5 WnEUi85Y3hJKxC5z+kp9J6xZ8ugMnZeCReaFD79oMfqtbVbKe1NwWewafEtaL5zpkDQM 0I3Dav02plFlsSbQ+jb2zN+9VpEaKo45haOrEHjM0jsKce1To1AfX/O34zaPYY8CkQa5 ED4i7kJChPO1cBB9z/w0mTPydiRfh2WTc3ICtOk8GtDsaFjEKpy22XOyg1KtG+aXTVd+ trPN18vlArmFI+E/Fx/g/0pHr2kuUCLv/FOC91mQ9oszq8ngqIREVp9vfNOrFDLX7rMM /3wA==
X-Gm-Message-State: ALoCoQmNRjP4JSPiv3bqrFR8U/HrEYGKRmZVnWxSOs60dMKD5UZtCAE3MSr9svFqnhVPdxF6Sq6/
X-Received: by 10.180.189.108 with SMTP id gh12mr4834853wic.53.1441126186567; Tue, 01 Sep 2015 09:49:46 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.179.221 with HTTP; Tue, 1 Sep 2015 09:49:06 -0700 (PDT)
In-Reply-To: <20150901161000.23052.16449.idtracker@ietfa.amsl.com>
References: <20150901161000.23052.16449.idtracker@ietfa.amsl.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 01 Sep 2015 09:49:06 -0700
Message-ID: <CABcZeBML87LjfUpeMwrrngNmO1S3WG5o-XZs1-k_6tY9n2jx=w@mail.gmail.com>
To: Alvaro Retana <aretana@cisco.com>
Content-Type: multipart/alternative; boundary="001a11c3420c6d5400051eb25656"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/CQYjT1D6yPhtBvwkR5uMolC677Y>
Cc: draft-ietf-tls-padding@ietf.org, The IESG <iesg@ietf.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Alvaro Retana's No Objection on draft-ietf-tls-padding-02: (with COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 01 Sep 2015 16:50:22 -0000

>
>
> As Alissa, I was wondering why it wasn’t easier to fix the one
> implementation instead.
>
>
Because it's widely fielded, and browsers don't know in advance what
kind of server they are talking to.




> The shepherd wrote: "Since then it has been found that this extension can
> server (sic) to alleviate issues with issues in several vendor's
> products.  There was good consensus to move forward with this document as
> it may find further applicability in the future.”  So it looks like the
> problem is not just one implementation…
>

There's another potential future application for DTLS to allow the client
to pad out the ClientHello to MTU size (or rather for the server to insist
on it) thus reducing the risk of amplification.

-Ekr


> If the WG now thinks that this extension may be valuable for other things
> besides fixing bugs, then it might be nice to reword some of the document
> to not focus on what seems to be one bug and just present the extension
> for what it is: padding.
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email