Re: [tcpinc] AD review of draft-ietf-tcpinc-tcpcrypt

"Black, David" <David.Black@dell.com> Mon, 18 September 2017 17:37 UTC

Return-Path: <David.Black@dell.com>
X-Original-To: tcpinc@ietfa.amsl.com
Delivered-To: tcpinc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63DD2133061; Mon, 18 Sep 2017 10:37:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.721
X-Spam-Level:
X-Spam-Status: No, score=-2.721 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=dell.com header.b=FFeOlz96; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=emc.com header.b=V+ZOF/qB
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 NHrWGkBW5b8P; Mon, 18 Sep 2017 10:37:11 -0700 (PDT)
Received: from esa3.dell-outbound.iphmx.com (esa3.dell-outbound.iphmx.com [68.232.153.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5B29132992; Mon, 18 Sep 2017 10:37:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1505756118; x=1537292118; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=quDwznbUblS74U8u5M/P/8cBko5kDb4ztVgodQ8DL/g=; b=FFeOlz96c80rjiLnS1HAdQ+Fk5yR8Lr+FKtrGHPUpRdnEG1RSk8eLYNK 8/FitkT5t328RKl1rBuuYJ7yCpFYRpwX0RSJEFsRu2xt5QljPEzmd2ymm Bn6MHkS0z7w7fAzTQeFFAV4m7VQdMwHEmNz6irWuy/fx/n0Y/hmZAWrHB k=;
Received: from esa1.dell-outbound2.iphmx.com ([68.232.153.201]) by esa3.dell-outbound.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 12:35:18 -0500
From: "Black, David" <David.Black@dell.com>
Received: from mailuogwdur.emc.com ([128.221.224.79]) by esa1.dell-outbound2.iphmx.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Sep 2017 23:35:20 +0600
Received: from maildlpprd52.lss.emc.com (maildlpprd52.lss.emc.com [10.106.48.156]) by mailuogwprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8IHb3GL006484 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Sep 2017 13:37:09 -0400
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v8IHb3GL006484
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=emc.com; s=jan2013; t=1505756230; bh=YJloQ0POmQH76caUvmVEZaVNI3E=; h=From:To:CC:Subject:Date:Message-ID:References:In-Reply-To: Content-Type:Content-Transfer-Encoding:MIME-Version; b=V+ZOF/qBrYfX/nKshZ9u9huuNDM4VIgvWpQo6xezN16yU+dEsH2JywrJDD60JdfeU jOLEyLasirT9W4TRCtM457RyTUStIf0oOpQgDiFWqsKoyC55fCtWVC4LrCOlMsrVsv vxvZik4yNstU8f4luKiSIDgUZAaxa1i4E9Q2z86U=
X-DKIM: OpenDKIM Filter v2.4.3 mailuogwprd51.lss.emc.com v8IHb3GL006484
Received: from mailusrhubprd51.lss.emc.com (mailusrhubprd51.lss.emc.com [10.106.48.24]) by maildlpprd52.lss.emc.com (RSA Interceptor); Mon, 18 Sep 2017 13:36:34 -0400
Received: from MXHUB318.corp.emc.com (MXHUB318.corp.emc.com [10.146.3.96]) by mailusrhubprd51.lss.emc.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.0) with ESMTP id v8IHanSi014943 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=FAIL); Mon, 18 Sep 2017 13:36:50 -0400
Received: from MX307CL04.corp.emc.com ([fe80::849f:5da2:11b:4385]) by MXHUB318.corp.emc.com ([10.146.3.96]) with mapi id 14.03.0352.000; Mon, 18 Sep 2017 13:36:49 -0400
To: =?utf-8?B?TWlyamEgS8O8aGxld2luZA==?= <ietf@kuehlewind.net>, "Daniel B Giffin" <dbg@scs.stanford.edu>
CC: "draft-ietf-tcpinc-tcpcrypt.all@ietf.org" <draft-ietf-tcpinc-tcpcrypt.all@ietf.org>, tcpinc <tcpinc@ietf.org>
Thread-Topic: [tcpinc] AD review of draft-ietf-tcpinc-tcpcrypt
Thread-Index: AQHTBttuU/+gR8A7okSsf0EGKVOXEaKd9pkAgAJKboCAGvoscA==
Date: Mon, 18 Sep 2017 17:36:49 +0000
Message-ID: <CE03DB3D7B45C245BCA0D243277949362FC597EB@MX307CL04.corp.emc.com>
References: <D38E22E9-FBB6-40D1-BF85-D5A77F5C2365@kuehlewind.net> <20170830223758.GA73969@scs.stanford.edu> <3a8ac0e0-cd41-57c8-85a4-79c5f179385f@kuehlewind.net>
In-Reply-To: <3a8ac0e0-cd41-57c8-85a4-79c5f179385f@kuehlewind.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.238.44.138]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Sentrion-Hostname: mailusrhubprd51.lss.emc.com
X-RSA-Classifications: public, GIS Solicitation
Archived-At: <https://mailarchive.ietf.org/arch/msg/tcpinc/PmgmPvnAUmt6kOKTWHYrlCxUHL0>
Subject: Re: [tcpinc] AD review of draft-ietf-tcpinc-tcpcrypt
X-BeenThere: tcpinc@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Working group mailing list for TCP Increased Security \(tcpinc\)" <tcpinc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tcpinc/>
List-Post: <mailto:tcpinc@ietf.org>
List-Help: <mailto:tcpinc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpinc>, <mailto:tcpinc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Sep 2017 17:37:13 -0000

+1 on Mirja's IANA comment:

> The assignment should only be made in one of the documents and I think  this
> one it the right one. So that should be removed from draft-ietf-tcpinc-tcpeno.

The two drafts will be read in concert by IETF LC reviewers and the ADs, so doing this twice will be noticed.

Thanks, --David


> -----Original Message-----
> From: Tcpinc [mailto:tcpinc-bounces@ietf.org] On Behalf Of Mirja Kühlewind
> Sent: Friday, September 1, 2017 5:37 AM
> To: Daniel B Giffin <dbg@scs.stanford.edu>
> Cc: draft-ietf-tcpinc-tcpcrypt.all@ietf.org; tcpinc <tcpinc@ietf.org>
> Subject: Re: [tcpinc] AD review of draft-ietf-tcpinc-tcpcrypt
> 
> Hi Daniel,
> 
> thanks for the edits. A few minor comments below. Those parts I removed
> look
> all good!
> 
> 
> >
> >> 2) Again IANA:
> >>     - This is probably rather a comment for tcp-eno but I just realized this
> now: Probably tcpcrypt should register itself in the "TCP encryption protocol
> identifiers“ created by the tcp-eno draft...
> >>     - Is the "tcpcrypt AEAD parameter“ registry a sub registry under the
> "Transmission Control Protocol (TCP) Parameters“ registry and what’s the
> registration policy for this new registry? I guess it could be good to also add a
> column in the registry for the respective RFCs that specify the algorithms…?
> >
> > Ok, I've tried to fix up the IANA section as follows.  (Note
> > that the TCP-ENO document includes these same tcpcrypt
> > values, as well as one for TCP-Use-TLS, in its listing of
> > "initial values" for the table.)
> >
> >    7.  IANA considerations
> >
> >       Tcpcrypt's TEP identifiers will need to be incorporated in IANA's
> >       "TCP encryption protocol identifiers" registry under the
> >       "Transmission Control Protocol (TCP) Parameters" registry, as in the
> >       following table.  The various key-agreement schemes used by these
> >       tcpcrypt variants are defined in Section 5.
> >
> >                 +-------+---------------------------+-----------+
> >                 | Value | Meaning                   | Reference |
> >                 +-------+---------------------------+-----------+
> >                 | 0x21  | TCPCRYPT_ECDHE_P256       | [RFC-TBD] |
> >                 | 0x22  | TCPCRYPT_ECDHE_P521       | [RFC-TBD] |
> >                 | 0x23  | TCPCRYPT_ECDHE_Curve25519 | [RFC-TBD] |
> >                 | 0x24  | TCPCRYPT_ECDHE_Curve448   | [RFC-TBD] |
> >                 +-------+---------------------------+-----------+
> >
> >                  Table 2: TEP identifiers for use with tcpcrypt
> >
> >       In Section 4.1, this document defines "sym-cipher" specifiers for
> >       which IANA is to maintain a new "tcpcrypt AEAD Algorithm" registry
> >       under the "Transmission Control Protocol (TCP) Parameters" registry,
> >       with initial values as given in the following table.  The AEAD
> >       algorithms named there are defined in Section 6.  Future assignments
> >       are to be made under the "RFC Required" policy detailed in [RFC8126],
> >       relying on early allocation [RFC7120] to facilitate testing before an
> >       RFC is finalized.
> >
> >            +-------+------------------------+------------+-----------+
> >            | Value | AEAD Algorithm         | Key Length | Reference |
> >            +-------+------------------------+------------+-----------+
> >            | 0x01  | AEAD_AES_128_GCM       | 16 bytes   | [RFC-TBD] |
> >            | 0x02  | AEAD_AES_256_GCM       | 32 bytes   | [RFC-TBD] |
> >            | 0x10  | AEAD_CHACHA20_POLY1305 | 32 bytes   | [RFC-TBD] |
> >            +-------+------------------------+------------+-----------+
> >
> >        Table 3: Authenticated-encryption algorithms corresponding to sym-
> >                  cipher specifiers in Init1 and Init2 messages.
> >
> >
> 
> The assignment should only be made in one of the documents and I think
> this
> one it the right one. So that should be removed from draft-ietf-tcpinc-
> tcpeno.
> 
> >
> >> 4) One technical comment/question:
> >> I think the following sentence in section 3.6 is actually not well enough
> defined:
> >> "In the latter case, the implementation MUST
> >>     either ignore the frame or abort the connection;“
> >>     - What does ignore in this case mean? This sounds like you ack the TCP
> segment but just don’t deliver the data… I guess that is not what you meant
> to say because that would break the TCP stream…? I guess you mean drop
> the TCP segment, right? In this case it’s probably useful to say somewhere
> that first the frame has to be decrypted and only if the decryption succeeds
> and ACK can be sent.
> >>     - Similar question for abort: Does this mean you send a TCP RST?
> >>     - Maybe it'd better to say that in general if encryption fails the TCP
> segment MUST be dropped. Failed decryption attempts SHOULD be logged
> and the connection MAY be reset if failure rate is high…?
> >
> > Okay yes, I've slightly modified that text to use the
> > clearer "drop segment" as you suggest:
> >
> > 			 In the latter case, the implementation MUST
> >     either drop the TCP segment(s) containing the frame or abort the
> >     connection; but if it aborts, the implementation MUST raise an error
> >     condition distinct from the end-of-file condition.
> >
> > I think the option to abort needs to be retained, as this is
> > likely to be the most convenient behavior for implementors
> > and for users (and doesn't make a tcpcrypt-protected
> > connection any more brittle than a plain one).  Still, the
> > "drop" option is there in case an implementation is able to
> > get some amount of DOS-resistance out of it.
> >
> > As for describing the abort behavior precisely, it feels
> > safer simply to use the expression "abort the connection"
> > from RFC793 instead of trying to summarize its semantics
> > here.
> >
> 
> So in RFC793, if I recognize correctly, abort is rather something like a
> silent close. Is this what you want, or would it make sense to send a reset?
> 
> 
> >
> >> - section 3.5
> >> "A host MUST NOT resume with a session secret if it has ever
> >>     successfully negotiated resumption in the past,...“
> >> Was this meant to mean „previous resumption attempt(s) failed“?
> Because if I read it like there was a least one successful resumption
> performed already, that’s not true for the first resumption attempt and
> therefore I could never use it…
> >
> > I'm not quite sure I understand what was confusing about
> > that wording, but I've adjusted it as follows to make sure
> > that "with the same secret" cannot be missed:
> >
> >     A host MUST NOT resume with a session secret if it has ever
> >     successfully negotiated resumption in the past with the same secret,
> >     in either role.
> >
> > Does this help at all?
> 
> No, what I meant is maybe to say this:
> 
> "A host MUST NOT resume with a session secret if it has already failed
>      to negotiated resumption in the past with the same secret,
>      in either role."
> 
> Is that still what you wanted to say? If so, I think that's more clear.
> 
> >
> >> - section 3.7
> >>     - It’s a bit confusing that FINp and URGp are explained quite extensively
> in this section while the frame format is specified later. Probably it's enough
> to say here that the FIN flag and the urgent pointer (URG) of the TCP header
> are protected (and the segment must be dropped if the protected values
> differ from the values in the TCP header).
> >>     - I also think this sentence is not quite correct:
> >>      "When "FINp" is set, it indicates that the sender will send no more
> >>     application data after this frame.“
> >>     When the FIN flag in the TCP header is set it indicates the sender will
> send no more payload data, however, the FINp is only the protected version
> of the FIN flag. It’s it’s a minor wording difference but it good to note that
> the TCP header information still define the normative behavior and also
> tcpcrypt does it to decide if the segment is value or not which cases a drop
> before the TCP precessing even starts.
> >
> > Yes, good points.  I've changed that language as follows in
> > order to make it clearer that we aren't interfering with TCP
> > semantics apart from defining when invalid segments must be
> > dropped:
> >
> >     A sender MUST set the "FINp" bit on the last frame it sends in the
> >     connection (unless it aborts the connection), and MUST set the TCP
> >     FIN flag on the last TCP segment used to transmit that frame.  A
> >     sender MUST NOT set the TCP FIN flag except on the last segment of a
> >     frame with "FINp" set.
> 
> 
> I would rather state this the other way around:
> 
> "If the TCP FIN is set (on the last segment), the sender MUST set the "FINp"
> bit on the last frame that is send in that segment (unless it aborts the
> connection). A sender MUST NOT set the "FINp" bit except when the TCP FIN
> flag is set on the segment carrying that frame."
> 
> I know that sounds a bit confusing and maybe you can phrase it better. The
> point is you should not re-define (normatively) when the TCP FIN flag must be
> set, as this is defined in RFC793 and it is not good practice to define
> things twice in different documents.
> 
> >
> >     Once a receiving host has received all segments containing a frame
> >     and has successfully decrypted the frame, it MUST verify that the TCP
> >     FIN flag in the last of these segments matches the "FINp" bit in the
> >     frame; if they differ, the receiving host MUST either drop the
> >     segments or abort the connection and raise an error condition
> >     distinct from the end-of-file condition.
> >
> > As for where this text should live, I agree it feels a
> > little scattered to have it separate from where the format
> > is defined, but now that the document has a major separation
> > between the semantics in "3. Encryption protocol" and the
> > formats in "4. Encodings", it seems best to stick with that
> > arrangement.
> >
> >
> >> - Any again, do you want to note Andrea especially in the
> acknowledgement? This has been done in previous drafts, so that nothing
> uncommon.
> >
> > Thanks for the thought.  We've discussed it and decided
> > Andrea would probably be most glad simply to have his
> > name on the work.
> >
> 
> Okay!
> 
> Thanks,
> Mirja
> 
> 
> _______________________________________________
> Tcpinc mailing list
> Tcpinc@ietf.org
> https://www.ietf.org/mailman/listinfo/tcpinc