Eric Rescorla has entered the following ballot position for
draft-ietf-tcpinc-tcpeno-13: Discuss
When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)
Please refer to https:/
Hi Ekr,
[writing as draft shepherd]
Let's see if the two of us can find some time in Singapore to talk about the
two crypto algorithm Discuss points (encryption and secure hash), as (IMHO) the
authors' intentions are good:
- Encryption: The intent is - don't use anything weaker than AES-128, e.
On Sun, Nov 12, 2017 at 5:08 AM, Black, David wrote:
> Hi Ekr,
> [writing as draft shepherd]
>
> Let's see if the two of us can find some time in Singapore to talk about
> the two crypto algorithm Discuss points (encryption and secure hash), as
> (IMHO) the authors' intentions are good:
>
Yep.
Hi David, hi Ekr,
just quickly on the discuss points: I’m actually wondering if we can just
remove the normative language here because it might be hard to give less
ambiguous guidance and if there is a new TEP it anyway will go through the IETF
process and we should/will not publish anything th
On Sun, Nov 12, 2017 at 1:13 PM, Eric Rescorla wrote:
> On Sun, Nov 12, 2017 at 5:08 AM, Black, David wrote:
>> - Encryption: The intent is - don't use anything weaker than AES-128,
>> e.g., don't even think about using 3DES. The concern is how to write that
>> requirement in a way that would su
On Sun, Nov 12, 2017 at 7:19 AM, Kyle Rose wrote:
> On Sun, Nov 12, 2017 at 1:13 PM, Eric Rescorla wrote:
> > On Sun, Nov 12, 2017 at 5:08 AM, Black, David
> wrote:
> >> - Encryption: The intent is - don't use anything weaker than AES-128,
> >> e.g., don't even think about using 3DES. The conc
Sorry, "not an unreasonable desire"
On Sun, Nov 12, 2017 at 7:21 AM, Eric Rescorla wrote:
>
>
> On Sun, Nov 12, 2017 at 7:19 AM, Kyle Rose wrote:
>
>> On Sun, Nov 12, 2017 at 1:13 PM, Eric Rescorla wrote:
>> > On Sun, Nov 12, 2017 at 5:08 AM, Black, David
>> wrote:
>> >> - Encryption: The int
Keeping this all on one thread, I think the situation on the three Discus
points is:
1) Encryption: Ekr and I need to talk about how to express “no weaker than
current strength of AES-128 (i.e., based on attacks known in 2017)”
2) The resolution for URG processing is clear – state that the list
On Mon, Nov 13, 2017 at 9:53 AM, Black, David wrote:
> Keeping this all on one thread, I think the situation on the three Discus
> points is:
>
>
>
> 1) Encryption: Ekr and I need to talk about how to express “no weaker than
> current strength of AES-128 (i.e., based on attacks known in 2017)”
>
Hi, Eric. Thanks for your review. Let me go through the discuss
points, but then below I have just a couple of questions about your
feedback. Most of your points I was able to address straight-forwardly.
Eric Rescorla writes:
> -
> > 1) Encryption: Ekr and I need to talk about how to express “no weaker than
> > current strength of AES-128 (i.e., based on attacks known in 2017)”
>>
> Yep. Happy to do this at a mutually convenient time.
I found something useful, as it turns out that I’ve seen this before in dealing
w/anoth
This seems fine to me. 124, 120, whatever it takes.
-Ekr
On Mon, Nov 13, 2017 at 10:41 AM, Black, David wrote:
> > > 1) Encryption: Ekr and I need to talk about how to express “no weaker
> than current strength of AES-128 (i.e., based on attacks known in 2017)”
> >>
>
> > Yep. Happy to do this
On Mon, Nov 13, 2017 at 10:37 AM, David Mazieres wrote:
> Hi, Eric. Thanks for your review. Let me go through the discuss
> points, but then below I have just a couple of questions about your
> feedback. Most of your points I was able to address straight-forwardly.
>
>
> Eric Rescorla writes:
Eric Rescorla writes:
>> >connection or when there is any ambiguity over the meaning of the SYN
>> >data. This requirement applies to hosts that implement ENO even when
>> >ENO has been disabled by configuration. However, note that
>> > I think you may mean to say "when the last SYN
On Mon, Nov 13, 2017 at 5:15 AM, David Mazieres <
dm-list-tcpcr...@scs.stanford.edu> wrote:
> Eric Rescorla writes:
>
> >> >connection or when there is any ambiguity over the meaning of the
> SYN
> >> >data. This requirement applies to hosts that implement ENO even
> when
> >> >ENO h
On Mon, Nov 13, 2017 at 6:12 AM, David Mazieres expires 2018-02-10 PST <
mazieres-8kczz844u5tupynhf38ddvt...@temporary-address.scs.stanford.edu>
wrote:
> Eric Rescorla writes:
>
> >> So in the first paragraph of the section, we define SYN TEP as follows:
> >>
> >> The meaning of data in a
David Mazieres expires 2018-02-10 PST
writes:
>> The problem is that "govern" is not very clear. It's clearer to link the
>> requirement
>> here to the specific feature of the packet.
>
> Okay, let me futz with the language a bit and try to get rid of or
> clearly define the term govern.
Okay, h
"Black, David" writes:
> I found something useful, as it turns out that I’ve seen this before in
> dealing w/another draft …
>o TEPs MUST NOT permit the negotiation of any encryption algorithms
> with significantly less than 128-bit security.
> To begin with, “permit the negotiation”
This seems fine to me.
On Mon, Nov 13, 2017 at 6:35 AM, David Mazieres <
dm-list-tcpcr...@scs.stanford.edu> wrote:
> David Mazieres expires 2018-02-10 PST
> writes:
>
> >> The problem is that "govern" is not very clear. It's clearer to link the
> >> requirement
> >> here to the specific feature
n Behalf Of David Mazieres
> Sent: Monday, November 13, 2017 2:32 AM
> To: Black, David ; Eric Rescorla
> Cc: tcpinc@ietf.org; Kyle Rose ; tcpinc-cha...@ietf.org;
> Black, David ; Mirja Kuehlewind (IETF)
> ; The IESG ; draft-ietf-tcpinc-
> tcp...@ietf.org
> Subject: R
David Mazieres writes:
>o TEPs MUST NOT permit the use of encryption algorithms with a
> security strength [SP800-57part1] of less than 120 bits. The
> intent of this requirement is to allow the use of algorithms such
> as AES-128 [AES] that are designed for 128-bit security
"Black, David" writes:
> This is entirely editorial about word choice - "permit the
> negotiation" sounds like a runtime requirement to me, whereas this
> section is entirely design requirements. Using "support" instead of
> "permit the negotiation of" is among the ways to make this clearer,
> I
On Mon, Nov 13, 2017 at 6:42 PM, David Mazieres <
dm-list-tcpcr...@scs.stanford.edu> wrote:
> "Black, David" writes:
>
> > This is entirely editorial about word choice - "permit the
> > negotiation" sounds like a runtime requirement to me, whereas this
> > section is entirely design requirements.
Hi David,
See [AB] below for a note about registration procedures.
Thanks,
Amanda
> --[3]-- IANA registry policy for TEP registry
>
>> Final point: I only have a tcpcrypt review from Barry Leiba. Should I
>> apply his suggestion of "IETF review" instead of "RFC Required"? I
>> originally wa
Eric Rescorla writes:
> To be honest, I think this document is working too hard in both cases to
> try to legislate that people don't do things that we think are bad. The
> bottom
> line is that in both cases the boundaries around what we think is OK and
> what we think is not are kind of fuzzy (
On Mon, Nov 13, 2017 at 9:24 PM, David Mazieres <
dm-list-tcpcr...@scs.stanford.edu> wrote:
> Eric Rescorla writes:
>
> > To be honest, I think this document is working too hard in both cases to
> > try to legislate that people don't do things that we think are bad. The
> > bottom
> > line is tha
eres
Cc: Black, David ; tcpinc@ietf.org; Kyle Rose
; tcpinc-cha...@ietf.org; Mirja Kuehlewind (IETF)
; The IESG ;
draft-ietf-tcpinc-tcp...@ietf.org
Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13:
(with DISCUSS and COMMENT)
On Mon, Nov 13, 2017 at
ity.
>
Well, ultimately this is a WG decision, but we actually have tried this
approach in TLS and other WGs and it doesn't work well. People grab code
points and we have to deal with that, and we also have to spend a lot of WG
time doing useless vetting when people just want a code point.
-Ekr
Only on this point:
> Am 14.11.2017 um 11:07 schrieb Eric Rescorla :
>
> --[3]-- IANA registry policy for TEP registry
>
>
>
> At least my suggestion of IETF Review was in part to see whether more strict
> review would be appropriate – that appears not to be the case, so …
>
>
>
> I like
On Tue, Nov 14, 2017 at 11:18 AM, Mirja Kuehlewind (IETF) <
i...@kuehlewind.net> wrote:
> Only on this point:
>
> > Am 14.11.2017 um 11:07 schrieb Eric Rescorla :
> >
> > --[3]-- IANA registry policy for TEP registry
> >
> >
> >
> > At least my suggestion of IETF Review was in part to see whether
Black, David writes:
> I like Amanda’s suggestion of: “Expert Review with RFC Required”
> That should result in two security reviews of a new TEP, both of
> which could halt a weak one. Looking at the Independent Submission
> track as the “path of least resistance” that would be the IETF
> Security
e ;
> tcpinc-cha...@ietf.org; Mirja Kuehlewind (IETF) ; The
> IESG ; draft-ietf-tcpinc-tcp...@ietf.org
> Subject: Re: [tcpinc] Eric Rescorla's Discuss on draft-ietf-tcpinc-tcpeno-13:
> (with DISCUSS and COMMENT)
>
> Black, David writes:
> > I like Amanda’s suggestion of:
Black, David writes:
> > We (talking as secdir secretary) do not do security reviews on the
> > independent submission documents. Area review teams only review IETF
> > stream documents and ignore other streams (Independent, IAB, IRTF
> > etc).
>
> Hmm - the process that I'd expect is that a SEC A
Amanda Baber writes:
> Hi David,
>
> See [AB] below for a note about registration procedures.
Okay, thanks. Here is my new proposed language for the end of IANA
considerations. This also reflects a change to address Benoit Claise's
concern that 95 TEP identifiers could prove too few.
Thi
We should rather put experts in place and not trying to push the responsibility
on the Sec AD. The conflict review is only to check if there are conflicts with
any IETF work and not to check if the work described is technically mature.
Mirja
> Am 14.11.2017 um 12:03 schrieb Tero Kivinen :
>
>
Hi David,
See [AB] below.
Thanks,
Amanda
On 11/13/17, 9:15 PM, "David Mazieres"
wrote:
Amanda Baber writes:
> Hi David,
>
> See [AB] below for a note about registration procedures.
Okay, thanks. Here is my new proposed language for the end of IANA
considerations. This also reflects a c
Hi,
See [AB] below.
On 11/13/17, 7:18 PM, "Mirja Kuehlewind (IETF)" wrote:
Only on this point:
> Am 14.11.2017 um 11:07 schrieb Eric Rescorla :
>
> --[3]-- IANA registry policy for TEP registry
>
>
>
> At least my suggestion of IETF Review was in part to see whether more strict
> review
Amanda Baber writes:
> I guess if we want expert review for non-IETF stream docs it actually
> would be „IETF Review or RFC Required with Expert Review“… Amanda,
> does that still makes sense to you?
>
> [AB] That works for us too. I think that in that case we would call it
> “IETF Review or Expe
Hi David,
This works for us. Thanks!
Amanda
On 11/15/17, 5:46 PM, "David Mazieres"
wrote:
Amanda Baber writes:
> I guess if we want expert review for non-IETF stream docs it actually
> would be „IETF Review or RFC Required with Expert Review“… Amanda,
> does that still makes sense to you?
>
39 matches
Mail list logo
