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

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,

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. ;)

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

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

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:

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

> On 15 Feb 2017, at 19:25, Martin Thomson <martin.thom...@gmail.com> wrote: > > On 16 February 2017 at 04:20, Yoav Nir <ynir.i...@gmail.com> wrote: >> No, not really, but TLS is not just the web, and there are connections that >> last for a long time and tran

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

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

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

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

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

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

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

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.

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

> On 2 Jan 2017, at 20:59, Eric Rescorla <e...@rtfm.com> wrote: > > > > On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: >> >> . >> >> Since I think the utility of this falls o

Re: [TLS] Harmonizing 4492bis with TLS 1.3

> On 14 Dec 2016, at 3:33, Martin Thomson <martin.thom...@gmail.com> wrote: > > On 13 December 2016 at 22:47, Yoav Nir <ynir.i...@gmail.com> wrote: >> 2. Change 4492bis: >> a. no new curves for ed25519 and ed448. >> b. Two new signature algorith

[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

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

> On 9 Dec 2016, at 23:43, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > Yoav Nir <ynir.i...@gmail.com> 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

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

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

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

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?

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 >>

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

> On 24 Nov 2016, at 15:47, Hubert Kario <hka...@redhat.com> wrote: > > On Wednesday, 23 November 2016 10:50:37 CET Yoav Nir wrote: >> On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: >>> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wr

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" > on behalf of > yaronf.i...@gmail.com > wrote: > >> So the key schedule

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

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 <ynir.i...@gmail.com> wrote: > > Hi. > > I’ve created a PR for TLS 1.3 > https://github.com/tlswg/tls13-sp

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

On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos <n...@redhat.com> wrote: > On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >> Hi, Nikos >> >> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos <n...@redhat.com> >> wrote: >> >>> >

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

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

[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

Re: [IPsec] Take a stand for key hygine

nd the other for TLS 1.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 Kivine

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

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

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

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 <ynir.i...@gmail.com> wrote: > > No, I think

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

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

[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

[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

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

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

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

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

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

> On 3 Nov 2016, at 20:20, Martin Rex <m...@sap.com> wrote: > > Yoav Nir wrote: >> >> On 3 Nov 2016, at 16:31, Martin Rex <m...@sap.com> wrote: >>> >>> Since then, I've seen exactly ZERO rationale why the cleartext contenttype, >>>

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: [IPsec] New Version Notification for draft-xu-ipsecme-esp-in-udp-lb-00.txt

unnel. > Furthermore, a 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..

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

> On 2 Nov 2016, at 18:19, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > Yoav Nir <ynir.i...@gmail.com> 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 netwo

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

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 >

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: > >

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

> On 18 Oct 2016, at 13:33, Tero Kivinen <kivi...@iki.fi> 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 al

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

> On 17 Oct 2016, at 19:19, Paul Wouters <p...@nohats.ca> 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. >

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

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

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

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

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

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 >

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

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

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

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

Re: [TLS] Industry Concerns about TLS 1.3

> On 23 Sep 2016, at 10:08 PM, Salz, Rich wrote: > > > Look, pretty much the entire world is being spied on by national-scale > adversaries who are recording all traffic for eventual decryption and > correlation. *Almost everyone* is having their traffic surveilled. The >

Re: [IPsec] Mirja Kühlewind's No Objection on draft-ietf-ipsecme-ddos-protection-09: (with COMMENT)

Hi. See responses below > On 23 Sep 2016, at 10:11 PM, Mirja Kuehlewind wrote: > -- > COMMENT: > -- > > Some questions: > > 1) sec

Re: [TLS] Industry Concerns about TLS 1.3

Hi, Andrew. Thank you for bringing these concerns to the list. I agree with Kenny that this is rather late, but it’s also true that I don’t think it would change the outcome of the consensus in this working group. The quest to mandate FS in TLS-using applications goes back longer than this

Re: [TLS] Suspicious behaviour of TLS server implementations

> On 22 Sep 2016, at 8:11 AM, Peter Gutmann wrote: > > Martin Thomson writes: > >> The advantage with deploying a new protocol is that you can be strict. If, >> for example, all of the browsers implement TLS 1.3 and are strict, then >>

Re: [TLS] [Cfrg] 3DES diediedie

> On 8 Sep 2016, at 7:08 PM, Kyle Rose wrote: > > On Thu, Sep 8, 2016 at 1:53 AM, Peter Gutmann > wrote: > The only data point I have is that every time I've tried to disable DES in > a new release (and by DES I

Re: [TLS] SHA-3 in SignatureScheme

> On 5 Sep 2016, at 11:17 AM, Nikos Mavrogiannopoulos wrote: > > On Fri, 2016-09-02 at 10:04 -0700, Eric Rescorla wrote: > I also am not following why we need to do this now. The reason we >>> defined SHA-2 in a new RFC was because (a) SHA-1 was looking weak and (b)

Re: [TLS] SHA-3 in SignatureScheme

> On 2 Sep 2016, at 10:28 PM, Blumenthal, Uri - 0553 - MITLL > wrote: > We have SHA-256 and SHA-384. > > No. By the same token we have AES-128, AES-256, ECDHE over P256, etc. > > I support adding SHA-3 to the core. > > Alternatively, feel free to throw ChaCha out and

Re: [TLS] SHA-3 in SignatureScheme

> On 2 Sep 2016, at 8:27 PM, Hubert Kario wrote: > > On Friday, 2 September 2016 12:06:55 CEST Benjamin Kaduk wrote: >> On 09/02/2016 12:04 PM, Eric Rescorla wrote: >>> On Fri, Sep 2, 2016 at 8:25 AM, Dave Garrett >> >>>

Re: [TLS] TLS 1.3 -> TLS 2.0?

> On 1 Sep 2016, at 6:31 PM, Dave Garrett wrote: > > On Thursday, September 01, 2016 02:05:25 am Judson Wilson wrote: >>> I like TLS/2 aesthetically, and represents a similar level of >>> progress/reset that HTTP saw when it jumped from 1.1 to /2. >> >> What is the

Re: [IPsec] Mirja Kühlewind's Block on charter-ietf-ipsecme-10-00: (with BLOCK)

> On 31 Aug 2016, at 3:21 PM, Tero Kivinen wrote: > > Mirja Kuehlewind (IETF) writes: >> thanks for the reply. Very helpful background info. Maybe even put >> more information in the charter text. > > I think it belongs to the actual draft, not to the charter, perhaps we >

Re: [IPsec] Stephen Farrell's Yes on charter-ietf-ipsecme-10-00: (with COMMENT)

Hi, Stephen > On 30 Aug 2016, at 4:38 PM, Stephen Farrell wrote: > I have a suggestion about this bit of work: > > "IKEv1 using shared secret authentication was partially resistance to > quantum computers. IKEv2 removed this feature to make the protocol > more

Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-04.txt

TF. > >Title : Curve25519 and Curve448 for IKEv2 Key Agreement > Authors : Yoav Nir > Simon Josefsson > Filename: draft-ietf-ipsecme-safecurves-04.txt > Pages : 7 > Date: 2

Re: [IPsec] 4307bis/7321bis key sizes

> On 23 Aug 2016, at 9:32 PM, Paul Hoffman wrote: > > On 23 Aug 2016, at 10:55, Paul Wouters wrote: > >> On Mon, 8 Aug 2016, Paul Wouters wrote: >> >> I haven't heard any objection to making 128 bit key sizes MUST- and >> 256 bit key sizes MUST. > > You can hear one

Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-02.txt

> On 8 Aug 2016, at 3:51 PM, Tero Kivinen <kivi...@iki.fi> wrote: > > Yoav Nir writes: >> Hi. >> >> New in this version: >> - A few textual changes in the Introduction (suggested by Tero) > > You seemed to skip my proposed changes for the IANA c

Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-02.txt

s. > This draft is a work item of the IP Security Maintenance and Extensions of > the IETF. > >Title : Curve25519 and Curve448 for IKEv2 Key Agreement > Authors : Yoav Nir > Simon Josefsson > Filename:

Re: [IPsec] New charter proposal

+1 > On 22 Jul 2016, at 9:35 AM, Michael Richardson wrote: > > > New charter seems fine. > > (I am pessimistic about the milestones, but I suggest changing them as needed > rather than planning to take longer.) > > -- > Michael Richardson ,

Re: [tcpinc] Why retain negotatiation

IIUC the idea is that the TLS work is not ended, merely suspended, and will resume once TLS 1.3 is out the door. Whether that will actually happen is of course not known. Yoav > On 16 Jul 2016, at 6:58 PM, Watson Ladd wrote: > > Dear all, > Originally negotiation was

Re: [IPsec] IETF 96 IPsecME Agenda

> On 7 Jul 2016, at 9:57 PM, Waltermire, David A. (Fed) > wrote: > > We are scheduled for 2pm - 4pm CEST on Tuesday, July 19th. The chairs need > to pull together an agenda for this meeting. Here is an early draft to get us > started: > > 10 minutes: agenda, WG

Re: [TLS] PR #23 for RFC4492bis

> On 4 Jul 2016, at 7:12 PM, David Benjamin <david...@chromium.org> wrote: > > On Mon, Jul 4, 2016 at 7:59 AM Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > > > On 4 Jul 2016, at 5:06 PM, Ilari Liusvaara <ilariliusva...@welho

[TLS] PR #23 for RFC4492bis

Hi Based on an email exchange with Nikos Mavrogiannopoulos, I’ve submitted a PR. https://github.com/tlswg/rfc4492bis/pull/23 If there are no objections, I will accept it and submit version -08 this Friday. Thanks Yoav ___ TLS mailing list

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

On 4 Jul 2016, at 12:44 PM, Paul Wouters <p...@nohats.ca> wrote: > On Sun, 3 Jul 2016, Yoav Nir wrote: > >>> 3) The Internet Draft Currently under consideration is not the best >>> starting point as it assumes that post-quantum pre-shared keys are the >

Re: [IPsec] Further thoughts on draft-flutter-qr-ikev2 as an IPsecME WG document

Hi, Mark > On 3 Jul 2016, at 9:08 PM, Mark McFadden wrote: > 3) The Internet Draft Currently under consideration is not the best starting > point as it assumes that post-quantum pre-shared keys are the preferred > solution for quantum resistance. This is not

Re: [IPsec] Endless stream of NAT-T keepalive probes?

All three devices also run an SSL-VPN, so you can just go to https:// to see who owns them. The first one will also tell you the vendor as they didn’t customize the landing page… > On 22 Jun 2016, at 7:11 PM, Paul Wouters wrote: > > > Hi, > > One of my machines is seeing a

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

2 IKEv2 > on using an implicit IV versus an explicit IV > > > Please let us know if that address your purpose. > > BR, > Daniel > > On Fri, Jun 10, 2016 at 2:01 AM, Yoav Nir <ynir.i...@gmail.com > <mailto:ynir.i...@gmail.com>> wrote: > Hi, Paul > &g

Re: [TLS] Consensus call for keys used in handshake and data messages

Hi, Nikos > On 15 Jun 2016, at 11:00 AM, Nikos Mavrogiannopoulos wrote: > > On Mon, 2016-06-13 at 12:00 -0700, Joseph Salowey wrote: >> For background please see [1]. >> >> Please respond to this message indicating which of the following >> options you prefer by Monday June,

Re: [TLS] Consensus call for keys used in handshake and data messages

> On 13 Jun 2016, at 10:00 PM, Joseph Salowey wrote: > > For background please see [1]. > > Please respond to this message indicating which of the following options you > prefer by Monday June, 20, 2016 > > 1. Use the same key for handshake and application traffic (as in

Re: [IPsec] New Version Notification for draft-mglt-ipsecme-implicit-iv-00.txt

Hi, Paul On 10 Jun 2016, at 5:42 AM, Paul Wouters wrote: > On Thu, 9 Jun 2016, Daniel Migault wrote: > >> Please find our new proposal with ESP using implicit IV [1]. We would like >> to present and discuss it at the next IETF meeting. > > I must understand it wrong... > >

Re: [TLS] Adoption of TLS-LTS

> On 8 Jun 2016, at 10:57 PM, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > > Yoav Nir <ynir.i...@gmail.com> writes: > >> Mostly timing. The TLS working group is now working on TLS 1.3, so 1.2 should >> be considered stable by now. > > As the

Re: [TLS] Adoption of TLS-LTS

> On 8 Jun 2016, at 10:29 PM, Peter Gutmann wrote: > > Russ Housley writes: > >> I do not think the TLS WG should take on any document that makes changes to >> the TLS 1.2 protocol. > > So how is that different from any number of other TLS

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

> On 7 Jun 2016, at 8:33 PM, Hubert Kario <hka...@redhat.com> wrote: > > On Tuesday 07 June 2016 17:36:01 Yoav Nir wrote: >> I’m not sure this helps. >> >> I’ve never installed a server that is version intolerant. TLS stacks >> from OpenSSL, Microsoft,

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

> On 7 Jun 2016, at 5:47 PM, Salz, Rich wrote: > >> I’m not sure this helps. > > I'm pretty sure it wouldn't help at all, for the reasons you list. Which isn’t to say it’s not worth doing. I’d love to test my implementation against a test suite rather than just making sure

Re: [TLS] [FORGED] Re: no fallbacks please [was: Downgrade protection, fallbacks, and server time]

I’m not sure this helps. I’ve never installed a server that is version intolerant. TLS stacks from OpenSSL, Microsoft, Java, and most any implementation we can name have been version tolerant forever. Certainly none of us can name any implementation that at any point had a version out that

Re: [IPsec] Status of draft-ietf-ipsecme-ddos-protection

> On 31 May 2016, at 8:01 AM, Valery Smyslov wrote: > > Hi Paul, > >>> On the other hand, if we go this way and give the puzzles stuff an >>> Experimantal status, then probably very few vendors (if any) will implement >>> it and the real problem of defending against >>>

Re: [IPsec] New version of TCP Encapsulation draft, request for adoption

> On 23 May 2016, at 9:39 AM, Valery Smyslov wrote: > > Hi Tommy, > > thank you for clarifications. One more point. The draft is silent about > what the responder is supposed to do with the stream prefix. > Should it check it? In this case what should it do if the prefix is >

Re: [TLS] [Technical Errata Reported] RFC5288 (4694)

> On 16 May 2016, at 6:50 AM, Atul Luykx wrote: > > Here's a possible re-write of the second paragraph: > > Nonce re-use in AES-GCM results in failure of both confidentiality and > authenticity. Not only will confidentiality be breached by leaking the XOR of >

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