[aqm] Review of draft-ietf-aqm-codel-07

Reviewer: Yoav Nir Review result: Has Nits Hi, I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editor

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

Hi This pull request addresses most of these comments. https://github.com/tlswg/rfc4492bis/pull/39 There is some discussion on that PR Some that are not addressed, I’ve answered below. Let me know if you want me to merge and submit. Yoav On

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

> On 19 Mar 2017, at 19:30, Eric Rescorla wrote: > > > > On Sun, Mar 19, 2017 at 10:23 AM, Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: > >> On 19 Mar 2017, at 16:55, Eric Rescorla > <mailto:e...@rtfm.com>> wrote: >> >> Overall: >

Re: [IPsec] Comments on draft-mglt-ipsecme-implicit-iv-02.tx

> On 19 Mar 2017, at 16:55, Eric Rescorla wrote: > > Overall: > I notice that you are using a construction different from that used > in TLS 1.3, which doesn't directly repeat nonces across associations. > > S 2. >This document does not consider AES-CBC ([RFC3602])as AES-CBC >requires t

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

> On 19 Mar 2017, at 13:20, Valery Smyslov wrote: > > Hi Yoav, > >> > I don't think it's a good idea. The TCP encapsulation has a lot of >> > drawbacks in terms of performance (see Section > 12), so it is considered >> > as a last resort if UDP doesn't work. In general UDP (or no encapsulation

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

Hi Valery. > On 19 Mar 2017, at 11:24, Valery Smyslov wrote: > > Hi Eric, > >> - It seems like IKE associations can span TCP connections (S 6) >> so why not instead of doing UDP first then TCP, do happy eyeballs. > > I don't think it's a good idea. The TCP encapsulation has a lot of drawbacks

Re: [IPsec] Comments on draft-ietf-ipsecme-tcp-encaps

Hi, Eric. > On 19 Mar 2017, at 4:04, Eric Rescorla wrote: > > [Now with the right address] > > I just finished reading this document. Some comments below. > > > - You have a uniform 16 bit length field followed by a 4 byte all-zeros >sentinel value to indicate that a packet is IKE rather

Re: [TLS] RFC 6066 - Max fragment length negotiation

hould not be infeasible. Yoav > On Thu, Mar 16, 2017 at 4:48 PM, Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: > Hi, Nitin. > > In section 7.4.1.4 of RFC 5246 it says: > >An extension type MUST NOT appear in the ServerHello unless the same >extension type

Re: [TLS] RFC 6066 - Max fragment length negotiation

Hi, Nitin. In section 7.4.1.4 of RFC 5246 it says: An extension type MUST NOT appear in the ServerHello unless the same extension type appeared in the corresponding ClientHello. So the answer is no. Only the client may request this. Yoav > On 16 Mar 2017, at 21:12, Nitin Shrivastav > w

Re: [TLS] Uplifting 5289

uplifted then. Yoav > On 16 Mar 2017, at 21:23, Eric Rescorla wrote: > > This is actually uplift to PS. > > On Thu, Mar 16, 2017 at 12:16 PM, Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: > >> On 16 Mar 2017, at 21:01, kathleen.moriarty.i...@gmail.co

Re: [TLS] Uplifting 5289

> On 16 Mar 2017, at 21:01, kathleen.moriarty.i...@gmail.com wrote: > > > > Please excuse typos, sent from handheld device > >> On Mar 16, 2017, at 11:37 AM, Yoav Nir wrote: >> >> >>> On 16 Mar 2017, at 17:17, Eric Rescorla wrote: >>>

Re: [TLS] Uplifting 5289

> On 16 Mar 2017, at 17:17, Eric Rescorla wrote: > > Hi folks > > I note that we are proposing to uplift RFC 5289 to PS, despite the fact that > it > standardizes some CBC cipher suites, which the WG is looking to move away > from. I recognize that these are the only cipher suites you can use

Re: [TLS] RFC4492bis next steps

OK, so I’ll merge the PRs tomorrow morning and start working on ekr’s comments over the weekend. Yoav > On 16 Mar 2017, at 14:41, Stephen Farrell wrote: > > > > On 16/03/17 06:20, Yoav Nir wrote: >> Hopefully I’ll be all done and ready to submit a new version as soon

[TLS] RFC4492bis next steps

Hi. There are now three PRs pending for this draft: https://github.com/tlswg/rfc4492bis/pulls These all look fine to me. There is also ekr’s review that requires some more changes: https://www.ietf.org/mail-archive/web/tls/current/msg22628.html

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

LGTM > On 15 Mar 2017, at 21:32, David Benjamin wrote: > > How's this look? https://github.com/tlswg/rfc4492bis/pull/37 > <https://github.com/tlswg/rfc4492bis/pull/37> > > On Wed, Mar 15, 2017 at 2:45 PM Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: >

Re: [TLS] Review of draft-ietf-tls-rfc4492bis-15

There is (going to be a re-spin). There already is a PR there. If you can make a PR to solve your issue, that would be great. > On 15 Mar 2017, at 19:20, David Benjamin wrote: > > If there's to be a respin anyway, I have another small editorial comment: > https://github.com/tlswg/rfc4492bis/iss

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-rfc7321bis-05: (with COMMENT)

Hi. I’d like to address the second comment. > On 15 Mar 2017, at 3:33, Stephen Farrell wrote: > - ENCR_NULL IMO ought be MUST NOT - did the WG discuss > that explicitly? If so, can you provide a pointer to the > archive? If not, does it still have to be a MUST? I do > wonder who wants to u

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

> On 15 Mar 2017, at 3:07, Sean Turner wrote: > > >> On Mar 14, 2017, at 18:57, Martin Thomson wrote: >> >> On 15 March 2017 at 09:05, Yoav Nir wrote: >>> A secure hash function such as the SHA-256, SHA-384, and SHA-512 >>> >>> [

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

> On 14 Mar 2017, at 23:29, Martin Thomson wrote: > > On 15 March 2017 at 08:26, Yoav Nir wrote: >> That is the document that was referenced by RFC 4492 and it’s from 1998. It >> doesn’t mention any hash function other than SHA-1. >> >> RFC 4492 said that

Re: [TLS] Kathleen Moriarty's Yes on draft-ietf-tls-rfc4492bis-15: (with COMMENT)

Hi, Kathleen. See inline. > On 14 Mar 2017, at 22:40, Kathleen Moriarty > wrote: > > Kathleen Moriarty has entered the following ballot position for > draft-ietf-tls-rfc4492bis-15: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the

Re: [TLS] TLS 1.3 and max_fragment_length

On 14 Mar 2017, at 13:04, Ilari Liusvaara wrote: > On Tue, Mar 14, 2017 at 11:10:54AM +0200, Yoav Nir wrote: >> >>> On 14 Mar 2017, at 5:38, Martin Thomson wrote: >>> >>> When we added padding to TLS 1.3, we created an ambiguity with the >>> max

Re: [TLS] WGLC: draft-ietf-tls-tls13-19

Hi. I will give the entire document a more thorough read, but I wanted to comment on section 1.2 earlier. Its title is “Major differences from TLS 1.2”, but the content is a change-log. The kind of change-log that usually gets deleted by the RFC editor. I hope we don’t plan to publish with sen

Re: [TLS] TLS 1.3 and max_fragment_length

> On 14 Mar 2017, at 5:38, Martin Thomson wrote: > > When we added padding to TLS 1.3, we created an ambiguity with the > max_fragment_length extension. > > Does the limit apply to len(TLSInnerPlaintext) or does it apply to > len(TLSInnerPlaintext.content) (i.e., TLSPlaintext.length)? That is,

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

with a different meaning, assigning the next > available value (currently 5) seems appropriate. > > Thanks, > David > > >> On Mar 12, 2017, at 11:14, Yoav Nir > <mailto:ynir.i...@gmail.com>> wrote: >> >> Hi, Daniel. >> >> See my comment

Re: [IPsec] Working group last call for the draft-nir-ipsecme-eddsa-00

Hi, Daniel. See my comments inline. Also see this pull request: https://github.com/ietf-ipsecme/drafts/pull/25 Unless I hear some push-back, I will submit this right before the deadline. Yoav > On 8 Mar 2017, at 20:49, Daniel Migault wrote: >

[TLS] Fwd: OPS-DIR review of draft-ietf-tls-rfc4492bis-14

Also forwarding to TLS I have created https://github.com/tlswg/rfc4492bis/pull/34 <https://github.com/tlswg/rfc4492bis/pull/34> I’ll merge this if there are no objections just before the submission cut-off and submit a new version. Yoav > Begin forwarded message: > >

Re: [TLS] "Spec Compliance" and the older TLS protocols

Hi, Brad What Martin said. Additionally, I work for a vendor that has to really “lawyer up” sometimes. So if RFC 2246 says “MUST implement X” and your code doesn’t implement X, just don’t claim compliance with RFC 2246. You can still have TLS 1.0 code for BC. In general, people looking for sta

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769).

Hi As an implementer I have no problem counting records, bytes or blocks (OK, the last you usually don’t count directly but (n+15)/16 is not beyond the capabilities of any implementer) So IMO whichever gives the tightest bound should be selected, and that means blocks. Exercising the rekey co

Re: [TLS] AD review of draft-ietf-tls-rfc4492bis-12.txt

> On 17 Feb 2017, at 18:58, Stephen Farrell wrote: > > > Hiya, > > I've had a read of this and asked for IETF LC to start. > > My comments below can be handled with any other IETF LC > comments. > > Thanks, > S. > > - Bits of this are fairly complex reading, given that ECC > isn't trivial a

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

> On 1 Mar 2017, at 15:06, Aaron Zauner wrote: > > >> On 24 Feb 2017, at 14:07, Salz, Rich wrote: >> >>> Assuming 256-bit AES-CCM suites are needed, I think the better place to put >>> them is in the TLS 1.3 document. >> >> That's a really big assumption. ;) >> >> I think the burden is on f

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

And they all cost 10 cents a piece, never get updated, and control the floodgates that hold back the biblical flood. > On 1 Mar 2017, at 16:28, Salz, Rich wrote: > > You know what amazes about IoT? No matter what someone tries to do there is > a chip/SoC out there that can't do it. > > Shrug

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

> On 24 Feb 2017, at 7:38, Joseph Salowey wrote: > > The difference between what is defined in 1.3 and this document is the 256 > bit CCM cipher suites. The document does not specify cipher suites for TLS > 1.3. > > Is it important for TLS 1.3 to have support for these cipher suites? > > I

Re: [TLS] Last call comments and WG Chair review of draft-ietf-tls-ecdhe-psk-aead

> On 22 Feb 2017, at 8:42, Martin Thomson wrote: > > On the interaction with TLS 1.3, we probably need a decision to be made: > > 1. strike TLS 1.3 from the document and only mention it in the way Joe > suggests, TLS 1.3 doesn't get the CCM suites (it already has the > equivalent of the GCM sui

Re: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-16.txt

Almost there. You didn’t reverse the complementary public keys (g**b or g**a) instead of (g**a or g**b) > On 16 Feb 2017, at 20:35, Paul Wouters wrote: > > On Thu, 16 Feb 2017, internet-dra...@ietf.org wrote: > >> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-16.txt > >> A diff f

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

> On 15 Feb 2017, at 19:25, Martin Thomson wrote: > > On 16 February 2017 at 04:20, Yoav Nir wrote: >> No, not really, but TLS is not just the web, and there are connections that >> last for a long time and transfer large amounts of data. Think datacenter >> synch

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

On 15 Feb 2017, at 19:05, Martin Thomson wrote: > > Frankly, I'm more concerned that this isn't small enough and that it > could it be practical to deploy an implementation that don't support > KeyUpdate. That would cause a real interop problem. Maybe we should resurrect [1] and add 3DES suppo

Re: [IPsec] Comments on draft-ietf-ipsecme-rfc4307bis

One correction > On 15 Feb 2017, at 19:05, Paul Wouters wrote: > >>> Nit: You need only one of the public values and the complementary >>> private value from the other side. >> >> Right. > > Instead of this: >exchange provides keys for the session. If an attacker can retrieve >one

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

> On 14 Feb 2017, at 23:52, Atul Luykx wrote: > >> Why is that 2^48 input blocks rather than 2^34.5 input blocks? > Because he wants to lower the security level. The original text recommends > switching at 2^{34.5} input blocks, corresponding to a success probability of > 2^{-60}, whereas his

Re: [TLS] [Cfrg] Closing out tls1.3 "Limits on key usage" PRs (#765/#769)

Hi, Quynh > On 14 Feb 2017, at 20:45, Dang, Quynh (Fed) wrote: > > Hi Sean and all, > > Beside my suggestion at > https://www.ietf.org/mail-archive/web/tls/current/msg22381.html > , I have a > second suggestion below. > > Just

Re: [TLS] TLS RSA-PSS and various versions of TLS

> On 8 Feb 2017, at 21:34, Timothy Jackson wrote: > > I have a question on RFC5246 (TLS 1.2) and how it’s going to interact with > RSASSA-PSS as we roll out TLS 1.3. Does the prohibition against RSASSA-PSS > apply only to the signatures that can be used for signing handshakes or does > it app

Re: [IPsec] [Editorial Errata Reported] RFC7296 (4930)

This is factually true, and it dates back to RFC 5996 (but not 4306). It obviously doesn’t confuse anyone, so I guess it should be either “held for document update” Yoav > On 8 Feb 2017, at 17:55, RFC Errata System wrote: > > The following errata report has been submitted for RFC7296, > "Inte

Re: [TLS] New Draft: Using DNS to set the SNI explicitly

On 7 Feb 2017, at 18:12, Ben Schwartz wrote: > Hi TLS, > > Like a lot of people here, I'm very interested in ways to reduce the leakage > of users' destinations in the ClientHello's cleartext SNI. It seems like the > past and current proposals to fix the leak are pretty difficult, involving

Re: [TLS] PSS and TLS 1.3

> On 6 Feb 2017, at 4:36, Martin Thomson wrote: > > On 6 February 2017 at 11:12, Nikos Mavrogiannopoulos wrote: >> TLS 1.3 requiring a different key type, will provide an incentive for >> them to update. > > > I don't think that's how this works. More likely, that would become a > reason not

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

> On 2 Jan 2017, at 20:59, Eric Rescorla wrote: > > > > On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <mailto:ynir.i...@gmail.com>> wrote: >> >> . >> >> Since I think the utility of this falls off as a reciprocal, I'll try >> making

Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values be fresh

On 31 Dec 2016, at 20:36, Adam Langley wrote: > Consider the motivations here: > > 1) We know that some implementations have gotten this wrong with TLS > 1.2 and cached values for far too long. Presumably if they were to be > naively extended to TLS 1.3 this issue would carry over. > > 2) We pr

Re: [TLS] Harmonizing 4492bis with TLS 1.3

> On 14 Dec 2016, at 3:33, Martin Thomson wrote: > > On 13 December 2016 at 22:47, Yoav Nir wrote: >> 2. Change 4492bis: >> a. no new curves for ed25519 and ed448. >> b. Two new signature algorithms, and request values 7 and 8 for them. >> c. ne

[TLS] Pull Request #26 for RFC4492bis

As Sean suggested, this PR removes two paragraphs from the Introduction section. They’re no longer needed in our opinion. https://github.com/tlswg/rfc4492bis/pull/26 If no objections are heard, I will merge this over the weekend. Yoav

[TLS] Harmonizing 4492bis with TLS 1.3

Hi One issue that came up during WGLC for 4492bis is the way EdDSA signatures are mentioned in SignatureAndHashAlgorithm and in In TLS 1.2 and 4492bis we have a SignatureAndHashAlgorithm struct with one byte for hash algorithm and another for signature algorithm.. The HashAlgorithm can be None

Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

> On 9 Dec 2016, at 23:43, Michael Richardson wrote: > > > Yoav Nir wrote: >> To get this working, the DNS64 should be on the remote tunnel endpoint >> or behind it. And this will require that it has an IPv6 address and >> knows to do the NAT64 translation

Re: [sunset4] [IPsec] ietf-nat64 - Internet VPN clients

> On 9 Dec 2016, at 23:43, Michael Richardson wrote: > > > Yoav Nir wrote: >> To get this working, the DNS64 should be on the remote tunnel endpoint >> or behind it. And this will require that it has an IPv6 address and >> knows to do the NAT64 translation

Re: [IPsec] [sunset4] ietf-nat64 - Internet VPN clients

> On 9 Dec 2016, at 18:32, Bjoern A. Zeeb > wrote: > > On 9 Dec 2016, at 16:07, Bill Fenner wrote: > >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick wrote: >> >>> Hi All, >>> >>> The sunset4 minutes suggest NAT64 SSID to become the default? >>> >>> Just checking, is there any summary on h

Re: [sunset4] [IPsec] ietf-nat64 - Internet VPN clients

> On 9 Dec 2016, at 18:32, Bjoern A. Zeeb > wrote: > > On 9 Dec 2016, at 16:07, Bill Fenner wrote: > >> On Fri, Dec 9, 2016 at 8:41 AM, Heatley, Nick wrote: >> >>> Hi All, >>> >>> The sunset4 minutes suggest NAT64 SSID to become the default? >>> >>> Just checking, is there any summary on h

Re: [IPsec] Quantum Resistant IKEv2

> On 8 Dec 2016, at 1:43, Michael Richardson wrote: > > > Scott Fluhrer (sfluhrer) wrote: >> o There is the option listed in the draft, where we modify both the >> KEYMAT and SKEYSEED computations; stirring it into the KEYMAT implies > > I read through the three options, and I have difficulty

Re: [TLS] Confirming consensus: TLS1.3->TLS*

> On 2 Dec 2016, at 19:58, David Benjamin wrote: > > (To clarify, I was not at all suggesting we go back to SSL. If we had a time > machine, I might make other suggestions, but as far as I know we do not.) Can’t we borrow one from tictoc? ___ TLS mai

Re: [TLS] Confirming consensus: TLS1.3->TLS*

> On 2 Dec 2016, at 10:33, Peter Gutmann wrote: > > Stephen Farrell writes: > >> IIRC that was sort-of a condition for adoption of the work in the IETF 20 >> years ago, when there were two different protocols already being deployed and >> the proponents of one of them said "we'll use that othe

Re: [TLS] record layer limits of TLS1.3

> On 24 Nov 2016, at 15:47, Hubert Kario wrote: > > On Wednesday, 23 November 2016 10:50:37 CET Yoav Nir wrote: >> On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos wrote: >>> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >>>> Hi, Nikos >&

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

> On 23 Nov 2016, at 12:22, John Mattsson wrote: > > On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer" > mailto:tls-boun...@ietf.org> on behalf of > yaronf.i...@gmail.com > wrote: > >> So the key schedule changed and therefore we think cross-version attacks >

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

Hi, John Thanks for the review. See my responses below: > On 23 Nov 2016, at 12:15, John Mattsson wrote: > > I have not read the processing parts in detail. Here are comments on the > first and last sections of the document. > > Cheers, > John > > - Somewhere > I suggest adding the following

Re: [TLS] Re-use and export of DH shares

And if it wasn’t clear, this *is* a WGLC comment on the TLS 1.3 draft based on discussion in Tuesday’s session in Seoul. Yoav > On 20 Nov 2016, at 12:21, Yoav Nir wrote: > > Hi. > > I’ve created a PR for TLS 1.3 > https://github.com/tlswg/tls13-spec/pull/768 > > It

Re: [TLS] record layer limits of TLS1.3

On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos wrote: > On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >> Hi, Nikos >> >> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos >> wrote: >> >>> >>> Hi, >>> Up to the current draft

Re: [TLS] record layer limits of TLS1.3

Hi, Nikos On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos wrote: > Hi, > Up to the current draft of TLS1.3 the record layer is restricted to > sending 2^14 or less. Is the 2^14 number something we want to preserve? > 16kb used to be a lot, but today if one wants to do fast data transfers > mos

Re: [TLS] Confirming consensus: TLS1.3->TLS*

> On 21 Nov 2016, at 20:43, Salz, Rich wrote: > > >> With this in mind, I'm voting in favor of any re-branding of TLS 1.3 where >> the >> protocol name remains "TLS" and major version becomes > 1. > > Me too. Agree ___ TLS mailing list TLS@ietf.o

[TLS] Re-use and export of DH shares

Hi. I’ve created a PR for TLS 1.3 https://github.com/tlswg/tls13-spec/pull/768 It adds a subsection to the Security Considerations section. It discusses key reuse (do it carefully or do it not). It has the "don't do this or this grape juice might ferment" weasel words suggested by someone at th

Re: [IPsec] Take a stand for key hygine

3, that won’t make server owners happy. > > I think it is a good idea to raise this issue in TLS WG. > > Regards, > Valery. > > > > From: Yoav Nir <mailto:ynir.i...@gmail.com> > Sent: 19 ноября 2016 г. 7:21 > To: Tero Kivinen <mailto:kivi...@iki.fi&g

Re: [IPsec] Take a stand for key hygine

> On 18 Nov 2016, at 5:38, Tero Kivinen wrote: > > Watson Ladd writes: >> I might be confused, but the slides in >> https://www.ietf.org/proceedings/97/slides/slides-97-ipsecme-signature-forms-ambiguity-in-ikev2-00.pdf >> seem to very clearly want something else. Apologies for my >> insufficient

Re: [TLS] Confirming consensus: TLS1.3->TLS*

Bleh. Can’t we get AOL to release the SSL trademark so that we can call it SSLv4? I hummed for TLS 4, so I’ll stay consistent: TLS 4. Yoav > On 18 Nov 2016, at 11:12, Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to somethi

Re: [IPsec] Take a stand for key hygine

Hi, Watson On 18 Nov 2016, at 9:18, Watson Ladd wrote: > Dear all, > > In reviewing the proceedings now online I noticed that someone is > proposing to support using the same key with multiple signature > algorithms. This is a bad idea that makes everyone sad. Showing that a > signature under o

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

But yes, I agree that IPsec, TLS and Curdle should come to the same conclusion either way. And I think that in light of existing deployment, Ed25519ctx *with* context is a very hard sell. Yoav > On 16 Nov 2016, at 15:32, Yoav Nir wrote: > > No, I think he means Ed448 an

Re: [IPsec] Resolving the Ed448 context issue in the EdDSA draft

gt; >> Yours, >> Daniel >> >> >> On Nov 16, 2016 1:35 PM, "Yaron Sheffer" > <mailto:yaronf.i...@gmail.com>> wrote: >> >> >> >>On 16/11/16 12:41, Paul Wouters wrote: >> >> >> >&g

[TLS] Resolving the Ed448 context issue in RFC4492bis

Hi, all As mentioned in Tuesday's session, Ed448 and Ed25519ctx add a new parameter to the signature function: a context string. Setting this string to a different value for each application (where application could be "PKIX", "TLS", "IKE") leads to different results and thus a signature made i

[IPsec] Resolving the Ed448 context issue in the EdDSA draft

Hi, all As mentioned in Tuesday's session, Ed448 and Ed25519ctx add a new parameter to the signature function: a context string. Setting this string to a different value for each application (where application could be "PKIX", "TLS", "IKE") leads to different results and thus a signature made i

Re: [TLS] Point validation in 1.3

I think the performance enhancement (in terms of handshakes per second) that you get by reusing ephemeral keys is so great, that we have to assume people will do it. You don’t have to keep the keys indefinitely. It’s fine to generate a new key every second or ten seconds or so. Which makes run

Re: [TLS] TLS Visibility Inside the Data Center (was: I-D Action: draft-green-tls-static-dh-in-tls13-00.txt)

If I understand this draft correctly, this draft describes server behavior. It does not change anything within the TLS 1.3 protocol. IOW a server doing this will interoperate with any client. I searched the tls13 draft to see if it has anything to say about this, and the only thing I found was

Re: [Captive-portals] capport lunch or Bar BoF in IETF97

Sounds interesting. I’ll try to make it. Yoav > On 13 Nov 2016, at 16:52, mariko kobayashi wrote: > > Hi, > How about meeting up around 12:00 in front of the reception desk(5th floor)? > > We're welcome more other guys will join us:) > > Best, > Mariko > > On 2016/11/13 2:21, Dave Dolson wr

Re: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-00.txt

s reserved soon? > > Thanks, > Tommy > >> On Oct 29, 2016, at 8:19 AM, Yoav Nir > <mailto:ynir.i...@gmail.com>> wrote: >> >> This version is similar to draft-nir-ipsecme-eddsa-01, with the following >> changes: >> Updated references >>

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

> On 3 Nov 2016, at 20:20, Martin Rex wrote: > > Yoav Nir wrote: >> >> On 3 Nov 2016, at 16:31, Martin Rex wrote: >>> >>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >>> which has existed through SSLv3-

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

I don’t think this makes any difference in applications written on commodity servers using regular socket APIs. It’s a kind of architecture that has a quick special purpose processor that terminates the TCP and splits the incoming stream into records. The application records are forwarded to a

Re: [TLS] Working Group Last Call for draft-ietf-tls-tls13-18

On 3 Nov 2016, at 16:31, Martin Rex wrote: > Since then, I've seen exactly ZERO rationale why the cleartext contenttype, > which has existed through SSLv3->TLSv1.2 would be a problem. With the > removal of renegotiation from TLSv1.3, it is even less of a problem to > keep the contenttype in the

Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

given traffic flow would be forwarded over a certain path and > therefore this is no disordering issue. As for why do we need a new port, I > had attempted to reply in another email. > > Best regards, > XIaohu > > 发件人: Yoav Nir [mailto:ynir.i...@gmail.com] > 发送时间: 20

Re: [dmarc-ietf] IETF Mailing Lists and DMARC

> On 2 Nov 2016, at 21:12, Ted Lemon wrote: > > FWIW, I use Google For Work (or whatever it's called this week) and it > doesn't automatically add DMARC headers--that's something that you > have to configure, apparently. So while I think that gmail.com is > probably a lost cause, if your org i

Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

> On 2 Nov 2016, at 18:19, Michael Richardson wrote: > > > Yoav Nir wrote: >> 4 Why do we need a new port? What goes wrong if the >> packets go to port 4500? > > I think that TE/load-balancer in the network calculates the same tuple hash > and so takes

Re: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

Hi, Xiaohu A few comments. Actually, they’re more like questions. How are IPsec SAs mapped to UDP pseudo-connections? Is it a 1:1 mapping between SPI and source port? If now, how do you deal with the packet reordering that the load balancer will do? IPsec requires ordered or nearly-ordered del

Re: [TLS] I-D Action: draft-ietf-tls-rfc4492bis-09.txt

ernet-Drafts > directories. > This draft is a work item of the Transport Layer Security of the IETF. > >Title : Elliptic Curve Cryptography (ECC) Cipher Suites for > Transport Layer Security (TLS) Versions 1.2 and Earlier > Authors : Yoav Nir >

Re: [IPsec] I-D Action: draft-ietf-ipsecme-eddsa-00.txt

xtensions of > the IETF. > >Title : Using Edwards-curve Digital Signature Algorithm > (EdDSA) in the Internet Key Exchange (IKEv2) >Author : Yoav Nir > Filename: draft-ietf-ipsecme-eddsa-00.txt > Pages : 5 > Date

Re: [IPsec] [IANA #932374] Protocol Action: 'Curve25519 and Curve448 for IKEv2 Key Agreement' to Proposed Standard (draft-ietf-ipsecme-safecurves-05.txt)

Hi, Amanda This seems correct. Thanks. Yoav > On 20 Oct 2016, at 22:43, Amanda Baber via RT > wrote: > > Dear Authors: > > ATTENTION: A RESPONSE TO THIS MESSAGE IS NEEDED > > We've completed the registry actions for the following RFC-to-be: > > draft-ietf-ipsecme-safecurves-05 > > We've

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

> On 18 Oct 2016, at 13:33, Tero Kivinen wrote: > > Yoav Nir writes: >> I’m not entirely comfortable with calling something a MUST NOT when all we >> have is conjecture, but I have no love and no need of those DH groups. > > Same here, and it also makes i

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

> On 17 Oct 2016, at 19:19, Paul Wouters wrote: > > On Mon, 17 Oct 2016, Yoav Nir wrote: > >> I’m not entirely comfortable with calling something a MUST NOT when all we >> have is conjecture, > > It's a little more than conjecture. > > 1) It has been

Re: [IPsec] [saag] trapdoor'ed DH (and RFC-5114 again)

I’m not entirely comfortable with calling something a MUST NOT when all we have is conjecture, but I have no love and no need of those DH groups. I don’t believe anyone else depends on these groups (at least in IPsec), so I’m fine with such a change. Yoav > On 17 Oct 2016, at 18:54, Daniel Mig

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-safecurves-05: (with COMMENT)

Hi, Stephen > > - Wouldn't it be good to encourage minimising re-use of > public values for multiple key exchanges? As-is, the text > sort-of encourages use for "many key exchanges" in > section 4. I don’t think so. Re-use reduces the computation cost of an IKE Responder (or TLS server) without

Re: [IPsec] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

Hi, Orit. I accepted most of your suggestions with a few exceptions below: > On 28 Sep 2016, at 0:30, Orit Levin wrote: > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for the > IETF Chair.

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

Hi, Orit. I accepted most of your suggestions with a few exceptions below: > On 28 Sep 2016, at 0:30, Orit Levin wrote: > > I am the assigned Gen-ART reviewer for this draft. The General Area Review > Team (Gen-ART) reviews all IETF documents being processed by the IESG for the > IETF Chair.

Re: [Gen-art] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

Thanks for that. For some reason gmail sent this to the spam folder. Yoav > On 7 Oct 2016, at 20:32, Kathleen Moriarty > wrote: > > Orit, > > Thanks for the review, making sure the editor see this. > > Kathleen > > On Tue, Sep 27, 2016 at 5:30 PM, Orit Levin >

Re: [IPsec] Gen-ART Last Call review of draft-ietf-ipsecme-safecurves-04

Thanks for that. For some reason gmail sent this to the spam folder. Yoav > On 7 Oct 2016, at 20:32, Kathleen Moriarty > wrote: > > Orit, > > Thanks for the review, making sure the editor see this. > > Kathleen > > On Tue, Sep 27, 2016 at 5:30 PM, Orit Levin >

Re: [IPsec] Interoperability problem concerning RFC 7427

Perhaps we (as in the working group) should schedule some time (15-20 minutes?) to discuss the options in Seoul. Understanding both RFC 7427 and PSS signatures when they are in certificates, but not PSS signatures when they are in AUTH payloads is a pretty egregious kind of wrongness, but if th

Re: [IPsec] Interoperability problem concerning RFC 7427

> On 4 Oct 2016, at 17:11, Valery Smyslov wrote: > > Hi Tero, >> [This is bit old email, but I have not seen any replies to this, and I >> am sending this as implementor not as chair.] >> Valery Smyslov writes: >>> The problem is that RFC7427 doesn't provide any means to find out >>> what kind

Re: [TLS] Industry Concerns about TLS 1.3

> On 28 Sep 2016, at 7:16 PM, Dan Brown wrote: > > As I understand the concern, the worry is that Bud is compromising Bob's > (TLS) server, to somehow send Bob's plaintext to the wrong place. > > The proposed (existing?) strategy has Bob compromising his own > forward-secrecy to stop Bud, bu

Re: [IPsec] Stephen Farrell's Yes on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

On 27 Sep 2016, at 8:09 PM, Stephen Farrell wrote: > This is a nicely written document... thanks! > > - I vaguely recalled that puzzles and IPR rang a bell. Did > the WG consider [1]? If not, and if it helps, I'm fine with > making a 3rd party declaration on that and last call could be > done

Re: [TLS] Industry Concerns about TLS 1.3

> On 27 Sep 2016, at 11:33 AM, Judson Wilson wrote: > > > > Yes, I know that changed. It was an example of something that works with > TLS 1.2 even when PFS is used. With TLS 1.3 server or client implementations > can find other ways to retain long-term records of session keys. The > capab

Re: [IPsec] Alexey Melnikov's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

> On 27 Sep 2016, at 2:42 PM, Valery Smyslov wrote: > > Hi Alexey, > > payload type for the Puzzle Solution Payload is specified in the last sentence > of Section 8.2: > > The payload type for the Puzzle Solution payload is . > > It is not included in the diagram in this section since the "N

Re: [IPsec] Flexible multi-factor authentication

Hi. It seems that what you are looking for is a generic way to transport arbitrary strings from server to client and back again. While not specifically intended for that, both EAP-GTC and EAP-OTP (types 6 and 5 respectively) have been (ab)used for that purpose. Not sure if that has happened in

<    1   2   3   4   5   6   7   8   9   10   >